Università degli Studi di Padova
←
→
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
Corso di Laurea in Informatica
PastBot: un bot per la piattaforma
Facebook Messenger per l’interazione con
gli utenti
Tesi di laurea triennale
Relatore
Prof. Mauro Conti
Laureando
Davide Polonio
Anno Accademico 2015-2016
Davide Polonio: PastBot: un bot per la piattaforma Facebook Messenger per l’interazione con gli utenti, Tesi di laurea triennale, c Ott 2016.
I problemi sono le uniche cose che dividono i sogni dalla realtà
Ringraziamenti Innanzitutto, vorrei esprimere la mia gratitudine al Prof. Mauro Conti, 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. Ho desiderio di ringraziare in particolar modo Franco per essermi sempre stato vicino anche quando non poteva e avermi sempre supportato nelle mie scelte, ma ringrazio anche tutti i miei amici per tutto il tempo passato insieme e le avventure vissute. Ultimi, ma non meno importanti, desidero ringraziare i miei compagni di corso Fabio, Andrea e Alessandro, con i quali ho avuto il piacere di condividere molte delle esperienze universitarie. Padova, Ott 2016 Davide Polonio
Sommario La presente tesi descrive il periodo di tirocinio, svoltosi durante il periodo di laurea triennale e della durata di circa trecento ore, del laureando Davide Polonio presso l’azienda PastBook, con sede ad Amsterdam, sotto la supervisione del professor Mauro Conti. Gli obiettivi dello stage erano la creazione di un bot tramite un’architettura serverless per la nuova piattaforma per bot di Facebook Messenger che permettesse all’utenza di usufruire di alcune funzionalità presenti nel sito web dell’azienda direttamente da una conversazione.
Indice
1 Introduzione 1
1.1 L’azienda PastBook . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Personale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2 Organizzazione interna . . . . . . . . . . . . . . . . . . . . . 2
1.1.3 Organizzazione dello sviluppo nel reparto tecnico . . . . . . 2
1.1.4 Attività di sincronizzazione giornaliere . . . . . . . . . . . . 2
1.1.5 Attività settimanali . . . . . . . . . . . . . . . . . . . . . . . 3
2 Il progetto 5
2.1 I ricordi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 L’era dei bot . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 PastBot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Azioni intraprendibili dall’utente . . . . . . . . . . . . . . . 7
2.2.2 Implementazione tecnica . . . . . . . . . . . . . . . . . . . . 8
3 Analisi dei requisiti 19
3.1 Requisiti di PastBot . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.1 UC0: caso d’uso generale . . . . . . . . . . . . . . . . . . . . 20
3.1.2 UC1: inizio conversazione per la prima volta in assoluto . . 21
3.1.3 UC2: invio richiesta di creazione di un nuovo album . . . . . 22
3.1.4 UC2.1: risposta affermativa al messaggio di conferma Crea-
zione nuovo album . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.5 UC2.2: risposta negativa al messaggio di conferma Creazione
nuovo album . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.6 UC2.3: creazione di un nuovo album . . . . . . . . . . . . . 23
3.1.7 UC3: invio richiesta di visualizzazione foto dell’album attivo 24
3.1.8 UC12: visualizzazione messaggio di errore album vuoto . . . 24
3.1.9 UC3.1: cancellazione singola foto . . . . . . . . . . . . . . . 25
3.1.10 UC3.2: visualizzazione singola foto nel browser . . . . . . . . 25
3.1.11 UC3.3: visualizzazione messaggio di errore cancellazione foto 26
3.1.12 UC3.4: acquisto album . . . . . . . . . . . . . . . . . . . . . 26
3.1.13 UC3.5: visualizzazione messaggio di errore acquisto album . 26
3.1.14 UC4: invio richiesta di informazioni sui costi . . . . . . . . . 27
3.1.15 UC5: invio comando di aiuto . . . . . . . . . . . . . . . . . 27
3.1.16 UC6: invio richiesta di visualizzazione album nel sito web . . 27
3.1.17 UC7: invio di un comando non valido . . . . . . . . . . . . . 28
3.1.18 UC8: invio di uno sticker . . . . . . . . . . . . . . . . . . . . 28
ixx INDICE
3.1.19 UC9: invio allegato . . . . . . . . . . . . . . . . . . . . . . . 28
3.1.20 UC10: visualizzazione messaggio di errore per tipo di allegato
non valido . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1.21 UC11: visualizzazione menù permanente . . . . . . . . . . . 30
3.1.22 UC11.1: creazione di un nuovo album . . . . . . . . . . . . . 30
3.1.23 UC11.2: visualizzazione delle foto dell’album esistente . . . . 31
4 Progettazione e codifica 33
4.1 Progettazione ed implementazione delle API . . . . . . . . . . . . . 33
4.1.1 Descrizione dell’architettura . . . . . . . . . . . . . . . . . . 33
4.1.2 Descrizione delle API . . . . . . . . . . . . . . . . . . . . . . 33
4.2 Descrizione del webhook . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3 Descrizione delle classi . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.1 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.2 api::putPastBotCollectionPhoto . . . . . . . . . . . . . . . . 35
4.3.3 api::getPastBotUser . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.4 api::getPastBotCollection . . . . . . . . . . . . . . . . . . . 35
4.3.5 api::createPastBotUser . . . . . . . . . . . . . . . . . . . . . 35
4.3.6 api::deletePastBotCollectionPhoto . . . . . . . . . . . . . . . 36
4.3.7 api::addPastBotMessage . . . . . . . . . . . . . . . . . . . . 36
4.3.8 api::createPastBotCollection . . . . . . . . . . . . . . . . . . 36
4.3.9 Webhook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5 Verifica e Validazione 39
6 Conclusioni 41
6.1 Raggiungimento degli obiettivi . . . . . . . . . . . . . . . . . . . . . 41
6.2 Bilancio formativo . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
A API Rest 43
A.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
A.2 REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
A.2.1 Identificazione delle risorse . . . . . . . . . . . . . . . . . . . 43
A.2.2 Utilizzo esplicito di metodi Hypertext Transfer Protocol
(HTTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
A.2.3 Risorse autodescrittive . . . . . . . . . . . . . . . . . . . . . 44
A.2.4 Collegamenti tra risorse . . . . . . . . . . . . . . . . . . . . 44
A.2.5 Comunicazioni prive di stato . . . . . . . . . . . . . . . . . . 44
Glossario 45
Acronimi 47
Bibliografia 49Elenco delle figure
1.1 Logo dell’azienda PastBook . . . . . . . . . . . . . . . . . . . . . . 1
2.1 Logo di PastBot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Presentazione del bot all’utenza finale . . . . . . . . . . . . . . . . . 7
2.3 Logo di Amazon AWS Lambda . . . . . . . . . . . . . . . . . . . . 9
2.4 Tipica struttura di un progetto Apex . . . . . . . . . . . . . . . . . 9
2.5 Logo di Apex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6 Logo di NPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7 Logo di APIGateway . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.8 Logo di Swagger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.9 Logo di Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.10 Logo di DynamoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.11 Logo di Messenger . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.12 Logo di DashBot . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1 UC0: caso d’uso generale . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 UC2: invio richiesta di creazione di un nuovo album . . . . . . . . . 22
3.3 UC3: invio richiesta di visualizzazione foto dell’album attivo . . . . 24
3.4 UC11: visualizzazione menù permanente . . . . . . . . . . . . . . . 30
4.1 Progettazione generale dell’applicazione . . . . . . . . . . . . . . . . 34
4.2 Rappresentazione UML di una API . . . . . . . . . . . . . . . . . . 34
4.3 Diagramma delle classi per la parte di PastBot relativa all’interazione
con gli utenti. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1 Logo del framework usato per i test Mocha . . . . . . . . . . . . . . 40
xiCapitolo 1
Introduzione
1.1 L’azienda PastBook
PastBook viene aperta a Milano nel 2011 come un hobby. Nel 2012 il fondatore,
capo tecnico e Scrum Master di eBay Italia Stefano Cutello, sposta l’azienda
ad Amsterdam per entrare nell’acceleratore per startup Rockstart. Grazie ai
finanziamenti dell’acceleratore e alla brillante idea la startup cresce diventando nel
2016 una società a tutti gli effetti.
L’idea di PastBook è quella di fornire un libro dei ricordi alle persone, prendendo
i momenti direttamente dai social network che ormai tutti siamo abituati ad usare.
Fornendo l’integrazione a diverse piattaforme l’applicazione permette di creare in
un unico sito il proprio album, per poi poterlo ordinare con diverse grandezze e
ottenere così una copia stampata.
figura 1.1: Logo dell’azienda PastBook
1.1.1 Personale
All’interno di PastBook il lavoro è suddiviso in diversi ruoli: servizio clienti,
programmatori e lato marketing.
Il servizio clienti si occupa di processare eventuali richieste dei clienti, come per
esempio modificare un libro dopo aver eseguito il pagamento, ottenere un rimborso
o avere più semplicemente informazioni riguardo al prodotto.
I programmatori si occupano della parte più tecnica del servizio: è importante
infatti mantenere aggiornata la piattaforma, aggiungendo funzionalità per attirare
continuamente nuovi clienti e rendere il sito il più appetibile possibile.
Il reparto marketing è legato al reparto tecnico. Ogni nuova funzionalità viene
infatti annunciata tramite i social network dell’azienda, per ottenere una massima
diffusione. Vengono anche pensate a strategie di mercato, come offerte speciali o
prezzi per nuovi prodotti.
12 CAPITOLO 1. INTRODUZIONE
1.1.2 Organizzazione interna
L’azienda, essendo comunque non di grosse dimensioni e avendo molta dinamicità
al suo interno aderisce alla tecnica Agile, in particolar modo Scrum.
1.1.3 Organizzazione dello sviluppo nel reparto tecnico
All’interno del reparto tecnico dove avviene lo sviluppo del codice sono state adottate
varie convenzioni riguardo all’organizzazione del sistema di versionamento e allo
stile di scrittura del codice.
Sistema di versionamento
Il sistema di versionamento, presenta diversi branch specifici per i vari ambienti di
lavoro:
∗ develop in questo ramo è presente il codice ancora in fase di sviluppo, che
deve essere sottoposto a revisione;
∗ qa qui è presente il codice attualmente sotto uno stato di revisione e testing,
in cui ci si vuole assicurare che tutte le attività implementate siano prive di
errori e rispondano come dovuto;
∗ prod in questo ramo è presente il codice attualmente impiegato nell’ambiente
di produzione, che viene ritenuto stabile e che ha passato i test di qualità.
Quando è necessario aggiungere nuove funzionalità i programmatori sono obbligati
a creare un nuovo ramo a partire da develop, che abbia come suffisso la scritta
feature/. Dopo questo suffisso, è necessario dare al ramo un nome esplicativo che
però non risulti troppo lungo.
Progettazione
Le funzionalità prima di essere implementate attraversano una fase di progettazione,
in cui il capo tecnico e il capo dell’azienda ne discutono, valutando il tempo a
disposizione e i costi in termini di risorse umane e di tempo. Se la funzionalità
viene ritenuta interessante, si passa a una progettazione di tipo tecnico, in cui il
capo tecnico decide le tecnologie migliori da utilizzare e le caratteristiche tecniche
che la funzionalità dovrà avere.
Viene adottata una progettazione volta a all’estensione: in questa maniera sarà
sempre facile poter aggiungere altre funzionalità a quelle già esistenti, per ottenere
quindi un prodotto che sia facilmente estendibile e che necessiti di meno tempo in
futuro per lo sviluppo, richiedendo di conseguenza anche meno risorse.
1.1.4 Attività di sincronizzazione giornaliere
Ogni sezione dell’azienda, ogni mattina, è tenuta ad aggiornarsi prendendo posto
nella sala apposita all’interno dell’ufficio. Qui i vari membri discutono e si aggiornano
riguardo alla situazione dei vari compiti da svolgere.1.1. L’AZIENDA PASTBOOK 3
1.1.5 Attività settimanali
Ogni lunedì di ogni settimana il reparto tecnico è chiamato all’attività di deploy
delle nuove funzionalità sviluppate la settimana prima. L’attività di deploy si
suddivide nei seguenti passi:
1. Fusione dei vari branch della nuova funzionalità sviluppata nel ramo denomi-
nato develop;
2. Caricamento del ramo develop in un ambiente di test;
3. Testing delle varie funzionalità per assicurarsi che tutto funzioni senza
problemi;
4. Una volta accertato che il tutto funzioni, fusione del ramo develop nel ramo
qa;
5. Ottenuta l’approvazione del capo tecnico, avviene il deploy della nuova funzio-
nalità nell’ambiente di produzione e il ramo qa viene fuso nel ramo prod, in
cui viene conservato tutto il codice che è attualmente eseguito nell’ambiente
di produzione.
Se la nuova funzionalità prodotta non viene ritenuta ancora matura per poterla
rilasciare in un ambiente di produzione si decide di rimandare la sua distribuzione
alla prossima successiva, avendo così il tempo di risolvere eventuali difetti riscontrati
nel periodo di testing.Capitolo 2
Il progetto
2.1 I ricordi
La vita di ogni persona è composta da ricordi. Sempre più oggigiorno la gente salva
i propri istanti tramite i social network, come ad esempio Facebook o Instagram.
Ma questi momenti tendono a svanire col tempo o possono perdersi nella vastità
di internet. Quello che PastBook offre è la possibilità di renderli permanenti in
un album fotografico prendendo i momenti salvati nei social network. Questa
operazione è resa ancora più semplice se il tutto è assistito da un bot, che rende il
processo più user-friendly.
2.1.1 L’era dei bot
Dal lancio iniziale sulla piattaforma di messaggistica di Telegram dei bot, si è
potuto notare come ci sia stato un maggior interessamento verso questa tecnologia.
L’entrata di Facebook tramite la sua applicazione di messaggistica Messenger ha
segnato un importante passo anche nel modo in cui le aziende possono interagire
con i propri clienti. È ora possibile scrivere direttamente alle pagine dei servizi
a cui si è interessati per ottenere aiuto o informazioni in pochi secondi, facendo
risparmiare agli utenti la fatica di andarsele a cercare nel sito della compagnia.
Questo ha fatto spingere i grandi colossi come Microsoft e Facebook stessa a
investire verso la branchia dell’intelligenza artificiale, per poter dare alle macchine
la possibilità di interpretare al meglio il linguaggio naturale degli esseri umani.
56 CAPITOLO 2. IL PROGETTO
2.2 PastBot
Appena uscita la possibilità di creare bot su Facebook e collegarli alle pagine delle
aziende PastBook si è subito attivata per creare il suo bot che aiuti le persone
nella creazione degli album in maniera interattiva rendendo facile il loro acquisto
in seguito. Questo permette anche agli utenti la creazione e l’acquisto di album
comodamente e direttamente da Facebook.
Una volta arrivato nella pagina della società, l’utente non deve far altro che
scrivergli un messaggio. Al primo messaggio si attiverà il bot che gli risponderà cor-
tesemente illustrandogli le sue funzionalità e comandi. L’utente potrà chiedere aiuto
al bot, che lo guiderà nei passi necessari per creare un album. Quando finalmente
l’utente ha inviato il numero minimo delle foto necessarie per creare l’album, verrà
informato da PastBot che gli offrirà la possibilità di acquistarlo. Questo porterà
l’utente in una procedura automatica di acquisto, in cui gli unici campi richiesti
saranno solamente selezionare il tipo di pagamento, la località dove spedire il libro
dei ricordi appena creato e in che formato lo si desidera.
figura 2.1: Logo di PastBot
Essendo l’utente un essere umano si è dovuto considerare dei possibili errori che
esso può commettere:
∗ errori in fase di digitazione;
∗ errori nell’invio delle immagini;
∗ errori nell’interpretazione dei messaggi del bot.
Errori di digitazione Per gli errori di digitazione il bot segnalerà all’utente
l’eventuale errore (se l’errore si trova nella parola chiave del comando), chiedendogli
di effettuare di nuovo l’operazione richiesta.
Errori nell’invio delle immagini Durante l’invio delle immagini, è possibile
che l’utente possa commettere un errore nella selezione e possa inviare anche altri
contenuti, come file generici o video. In questo caso, il bot ignorerà i contenti diversi
da immagini che sono stati inviati, senza lanciare un messaggio di errore o fermare
l’operazione di caricamento. Questa scelta è stata presa in quando è possibile che
questo tipo di errore avvenga maggiormente quando l’utente vuole inviare un gran
numero di foto nella conversazione, ed eseguire azioni come segnalare l’errore o
fermare il processo di salvataggio delle immagini potrebbe portare a reazioni come
frustrazione e fastidio.2.2. PASTBOT 7
Errori di interpretazione È anche possibile che le persone commettano degli
errori nell’interpretare il senso della frase che il bot manda loro. Questo potrebbe
portare a un errore nella procedura richiesta dal bot. Un tipico esempio potrebbe
essere richiedere la lista delle foto di un album che è attualmente vuoto. In questo
caso il bot segnalerà all’utente che l’azione non è disponibile, e provvederà a fornirgli
una lista di azioni che può intraprendere. In questa maniera si inviterà a continuare
attivamente la conversazione.
figura 2.2: Presentazione del bot all’utenza finale
2.2.1 Azioni intraprendibili dall’utente
L’utente può intraprendere con PastBot diversi tipi di azioni. Di seguito si elencano
le possibili:
∗ richiedere informazioni riguardo al funzionamento del bot;
∗ richiedere informazioni riguardo ai costi di spedizione e ai formati degli album;
∗ creare un nuovo album;
∗ inviare foto al bot tramite la chat utente;
∗ vedere la lista delle foto inviate e attualmente presenti all’interno dell’album;
∗ richiedere di vedere, a grandezza originale e senza alcuna riduzione di risolu-
zione, un’immagine presente nella lista dell’album che si sta creando;
∗ richiedere di cancellare una specifica foto dall’album che si sta creando;
∗ procedere con l’acquisto dell’album.8 CAPITOLO 2. IL PROGETTO
2.2.2 Implementazione tecnica
Amazon AWS Lambda
PastBook basa i suoi servizi nel cloud grazie a Amazon AWS Services. Per realizzare
il bot è quindi stato deciso di pensarlo utilizzando un’architettura serverless con
database non relazionali (ovvero di tipo NoSQL). Un’architettura di questo tipo
porta a diversi vantaggi:
∗ nessun costo di amministrazione dei server in cui il programma viene eseguito;
∗ l’applicazione ha la possibilità di scalare in automatico in base alle richieste
in arrivo, per offrire un servizio all’utenza senza interruzioni;
∗ i costi sono legati solamente al tempo di esecuzione effettivo del programma
nel cloud;
∗ risorse automaticamente gestite;
∗ reigstrazione automatica degli eventi dell’applicazione;
∗ raccolta automatica di metriche e statistiche sull’utilizzo delle risorse;
∗ tutto l’ambiente è all’interno dello stesso cloud, permettendo una comuni-
cazione interna molto rapida e riducendo i tempi di chiamate delle varie
API.
Questo tipo di vantaggi ha permesso anche durante il tirocinio di focalizzarsi preva-
lentemente nella stesura del codice senza preoccuparsi della parte di amministrazione
del sistema.
Il servizio cloud utilizzato nello specifico si chiama Amazon AWS Lambda, e
permette di configurare quante risorse per quanto tempo il programma potrà avere.
AWS Lambda permette di caricare il codice sotto forma di funzioni. Queste funzioni
non sono altro che porzioni di codice (che possono essere composte da più file).
Nella configurazione sarà poi necessario definire il metodo della funzione da invocare
al sopraggiungere di una richiesta. A questa funzione verrà passato un evento sotto
forma di oggetto JSON. I campi per l’oggetto sono definibili e personalizzabili
nella configurazione della funzione, oppure si può scegliere di ricevere tutti i campi
dell’evento. Per poter automatizzare anche questa configurazione, creando quindi
un sistema completamente automatizzato per la distribuzione del codice, si è deciso
di utilizzare lo strumento liberamente disponibile Apex.2.2. PASTBOT 9
figura 2.3: Logo di Amazon AWS Lambda
Apex
Apex è uno strumento che permette di automatizzare la fase di distribuzione del
codice sorgente con configurazioni personalizzabili in base all’ambiente in cui si
distribuisce il programma. Oltre a queste funzionalità, permette anche di:
∗ eseguire la funzione direttamente da linea di comando (il codice verrà comun-
que eseguito in remoto);
∗ visualizzazione di metriche sull’utilizzo del programma;
∗ visualizzazione dei registri di esecuzione.
Per utilizzare questo strumento è stato necessario creare la struttura del progetto
secondo quanto specificato dalla documentazione del programma.
figura 2.4: Tipica struttura di un progetto Apex
Struttura di un progetto Apex Come è possibile notare nella figura, sono
presenti diversi file di configurazione di tipo JSON. Prima dell’estensione del file è
possibile notare come siano appuntati i vari tipi di environment, per cui è possibile
creare una configurazione diversa. All’interno del file project..json è
possibile inserire i seguenti campi:10 CAPITOLO 2. IL PROGETTO
∗ name: il nome del progetto;
∗ description: una descrizione del progetto (questo campo può essere opziona-
le);
∗ runtime: specifica ad Apex il tipo di linguaggio e la versione dell’interprete
per il linguaggio scelto che è necessario utilizzare. Le versioni attualmente
supportate dallo strumento sono maggiori di quelle che permette il servizio
Amazon Lambda, che è limitato solamente ai linguaggi come JavaScript,
Python e Java. Le opzioni disponibili per questo campo sono:
– java (utilizzo di Java versione 8)
– python (versione 2.7)
– nodejs (versione 0.10)
– nodejs4.3 (versione 4.3)
– golang (qualsiasi versione)
∗ memory: la memoria che le varie macchine Lambda disporranno. La memoria
utilizzabile varia da un minimo di 128 MB di Random Access Memory (RAM)
fino a un massimo di 1536MB di RAM. Questo campo richiede l’inserimento
di un valore intero;
∗ timeout: indica il tempo massimo di esecuzione della singola funzione Lamb-
da: infatti è possibile che la macchina abbia dei periodi di esecuzione più
lunghi di quelli desiderati. Se l’esecuzione supera il limite impostato verrà
interrotta. Questo valore attualmente può essere impostato a un massimo di
5 minuti;
∗ role: all’interno dell’ambiente Amazon AWS sono presenti i ruoli, che danno la
possibilità di definire i permessi delle varie risorse all’interno del servizio, siano
essi utenti della compagnia o servizi in esecuzione. Ogni permesso è identificato
tramite un Amazon Resource Name (ARN), che segue la definizione:
arn:partition:service:region:account-id:resource
dove:
– arn identifica che si tratta di un ruolo;
– partition indica il tipo di luogo in cui si trova la risorsa. Attualmente
è solamente disponibile il valore aws;
– service indica il servizio. Nel caso della configurazione necessaria per il
tirocinio, il valore è stato impostato a lambda;
– region indica la regione dove questa risorsa è allocata. Amazon AWS
Services è un servizio presente in più regioni del mondo, e ogni regione
permette di avere una propria configurazione;
– account-id indica l’id dell’account con cui si sta assegnando il permesso;2.2. PASTBOT 11
– resource è il nome della risorsa, che è univoco per quel determinato
servizio nella regione selezionata.
L’assegnazione di un ruolo è obbligatorio e se non correttamente configura-
to durante l’esecuzione del codice si potrebbero riscontrare problemi con i
permessi.
∗ name-template: questo campo indica il nome che la funzione avrà quando
sarà caricata nel servizio Amazon Lambda. Questo nome infatti può essere
personalizzato usando delle sequenze predefinite. Seguendo le convenzioni
stabilite all’interno di PastBook, il nome è stato definito in questa maniera:
{{.Project.Environment}}-{{.Function.Name}}
Dove nella prima parte sarà il tipo di ambiente (environment) in cui verrà
caricata la funzione (ovvero o dev o qa o prod ) mentre nella seconda si avrà il
nome della cartella che ospita il codice della funzione;
∗ handler: questo parametro indica il nome del metodo della funzione che
Amazon Lambda chiamerà quando ne sarà richiesta l’esecuzione.
Una volta definito il file di configurazione per il progetto è possibile cominciare
a lavorare sulle funzioni che poi verranno caricate nel servizio Amazon Lambda.
Queste funzioni devono trovarsi all’interno di una propria cartella all’interno di
function. Il nome della cartella indicherà anche il nome della funzione: per ogni
funzione è poi possibile scrivere il codice che verrà eseguito.
Personalizzazione delle configurazioni Apex è uno strumento flessibile che
permette di definire in maniera dettagliata ulteriori configurazioni per ogni funzione,
tramite la definizione di un file function..json. Anche questo file è
un oggetto di tipo JSON, con gli stessi campi del file project..json:
ciò permette una ridefinizione dei valori dei campi che si vuole personalizzare per
quella funzione, consentendo quindi la creazione di una configurazione globale per
tutto il progetto e una personalizzata per ogni funzionalità. Come convenzione
interna della compagnia è stato deciso di nominare tutti i file principali che vengono
poi eseguiti dal servizio Lambda con il nome di index.js.
figura 2.5: Logo di Apex12 CAPITOLO 2. IL PROGETTO
NPM
Il bot durante lo sviluppo ha richiesto la necessità di dipendenze di terze parti, e
per questo è stato deciso di integrarle tramite il gestore di moduli JavaScript Node
Package Manager (NPM).
NPM provvede a fornire una serie di moduli creati da altri utenti. Questi moduli
possono instaurare dipendenze tra di loro, creando un sistema in cui il riutilizzo
gioca un ruolo chiave. Questa cooperazione di pacchetti permette la creazione di
altro software in maniera più semplice. NPM offre anche la possibilità di rendere
i pacchetti privati e non condivisibili pubblicamente, consentendo ad aziende di
sviluppare codice proprietario in moduli per riutilizzarlo per diversi progetti interni.
All’azione di caricamento, Apex riconosce la dipendenza da altri moduli Java-
Script, provvedendo quindi a generare un file compresso che li contenga tutti e a
caricarli nel servizio.
figura 2.6: Logo di NPM
Progettazione della struttura serverless
La progettazione di un’architettura di tipo serverless ha portato alla creazione di
due parti principali del bot, ovvero una parte dedicata solamente alla ricezione dei
messaggi e all’interazione con l’utente e la rimanente per eseguire le operazioni
sui database non relazionali. La parte riguardante le operazioni sui database non
relazionali è stata suddivisa ulteriormente, e ogni funzionalità è stata posta in
una funzione AWS Lambda apposita, in maniera tale da aver una miglior gestione
delle risorse. Si è deciso di chiamare questa parte API. Le API decise in fase di
progettazione sono state le seguenti:
∗ addPastBotMessage: aggiunge i messaggi ricevuti nel database ai fini di
raccolta dati;
∗ createPastBotCollection: questa API si occupa della creazione di nuovi
album;
∗ createPastBotUser: si occupa della creazione dei nuovi utenti che scrive-
ranno a PastBot;
∗ deletePastBotCollectionPhoto: si occupa della cancellazione di una sin-
gola foto da una determinata collezione;
∗ getPastBotCollection: ritorna la collezione attualmente attiva dato un id
di un utente iscritto;
∗ getPastBotUser: ritorna tutte le informazioni attualmente presenti su
quell’utente, come la lista delle collezioni create e la lista attualmente attiva;2.2. PASTBOT 13
∗ putPastBotCollectionPhoto: dato un URL di un’immagine valido, prov-
vede ad aggiungere quell’immagine nel database di PastBot assegnandola
all’ultima collezione di foto attiva.
Questa suddivisione tra API e il bot che ha il compito di ricevere i messaggi è
stata determinata anche grazie al servizio Amazon AWS APIGateway.
APIGateway
APIGateway è uno dei molti servizi presenti all’interno di Amazon AWS Services
e serve per la gestione e l’instradamento delle richieste. Oltre a permettere la
definizione e la gestione di API in maniera semplice mette anche a disposizione:
∗ integrazione nativa di con tutti gli altri servizi offerti da Amazon AWS;
∗ gestione integrata dei permessi e controllo degli accessi;
∗ monitoraggio del volume di richieste;
∗ versionamento delle API;
∗ grazie alla distribuzione del servizio in varie parti del mondo viene assicurata
una bassa latenza per prestazioni maggiori.
La definizione di un determinato URL permette di configurare l’evento ad esso
associato in base al tipo di richiesta CRUD. Al momento della definizione, è
necessario selezionare quale servizio gestirà la richiesta. Ai fini del progetto, a ogni
URL è stata associato una chiamata a una specifica funzione Lambda.
In questa maniera, tramite l’utilizzo di un gestore di API si è potuto definire un
servizio serverless ben incapsulato: infatti chi andrà a effettuare le chiamate alle
varie API non sarà a conoscenza di come esse sono strutturate internamente e di
come esse verranno gestite. Le API hanno richiesto una loro definizione e una loro
progettazione prima di essere implementate su APIGateway, e per compiere questo
passo si è ricorsi allo strumento Swagger.
figura 2.7: Logo di APIGateway14 CAPITOLO 2. IL PROGETTO
Swagger
Swagger è uno strumento potente che permette la rappresentazione di API per il
web con relativa documentazione. È utilizzabile tramite la definizione di un file
di configurazione di tipo YAML: in questa maniera si vengono a definire i punti
d’accesso all’applicazione e se ne compie anche una loro descrizione. È possibile
definire il file di tipo YAML tramite l’aiuto di un apposito editor di testo.
La decisione di usare questo strumento per definire i punti d’accesso all’appli-
cazione è stata presa in merito al supporto nativo che il servizio Amazon AWS
APIGateway fornisce a Swagger. Si è proceduti quindi nella seguente maniera:
1. progettazione dei punti d’accesso all’applicazione;
2. definizione dei punti d’accesso in un file Swagger;
3. configurazione del servizio APIGateway tramite il caricamento del file Swagger.
L’utilizzo di un file di configurazione porta alla possibilità di tenere il file sotto uno
strumento di versionamento, e quindi di poterne avere sempre una storia associata
al progetto, inoltre, in caso ci siano problemi o errori sarà più facile individuali
essendo la definizione tutta in un unico file, e non distribuita nell’interfaccia grafica
dello strumento di comando di APIGateway. Il sistema di versionamento utilizzato
durante il tirocinio è stato Git.
figura 2.8: Logo di Swagger2.2. PASTBOT 15
Git
Git è un sistema di versionamento, ovvero uno strumento che aiuta i programmatori
a tenere traccia delle modifiche che un file o una porzione di codice ricevono.
Utilizzare questo sistema di versionamento ha diversi vantaggi anche a livello
organizzativo, e ha permesso durante la codifica di sperimentare diverse soluzioni
ai problemi incontrati tramite l’utilizzo di diversi rami di sviluppo. Grazie a tale
strumento, si è anche potuto evitare casi di sovrascrittura del codice, ovvero quando
due programmatori vanno a modificare una medesima porzione del programma.
A ogni versione stabile del software raggiunta nel ramo prod, si è deciso di
rilasciare un tag, ovvero un’etichetta che identifica in maniera univoca quella
determinata versione del codice. Così facendo, si può avere uno storico delle versioni
stabili.
figura 2.9: Logo di Git
DynamoDB
DynamoDB è un altro dei servizi che Amazon AWS mette a disposizione. Questo
offre un database flessibile di tipo NoSQL, per tutti quei servizi che necessitano di
poca latenza e debbano scalare in un futuro. AWS DynamoDB è totalmente gestito
da Amazon, ed è consigliato per le applicazioni legate al mondo del web. Ai fini
di PastBot, DynamoDB è stato essenziale per salvare i messaggi, gli utenti e gli
album con gli indirizzi alle relative foto. Il trasferimento dei dati è stato eseguito
inviando direttamente oggetti di tipo JSON al database.
figura 2.10: Logo di DynamoDB16 CAPITOLO 2. IL PROGETTO
Messenger e Facebook
PastBot è nato per essere integrato con le API della piattaforma di messaggistica
istantanea Facebook Messenger. Prima di poter cominciare a sviluppare un bot per
la piattaforma Messenger è necessario creare un’applicazione dalla sezione dedicata
agli sviluppatori per Facebook. Una volta creata l’applicazione, è stato possibile
creare un codice identificativo univoco utilizzabile dal bot per inviare e ricevere
contenuti.
Messenger mette a disposizione una lista selezionabile di eventi che si desidera
inviare al bot, dove gli eventi sono:
∗ ricezione di un messaggio;
∗ pressione di un bottone o di un link dal menù permanente;
∗ ricezione di un messaggio dal bottone Invia a Messenger;
∗ ricezione della notifica di ricezione del messaggio da parte dell’utente;
∗ ricezione del messaggio inviato all’utente (anche detto echo).
Le azioni eseguibili dal bot sono la notifica all’utente che si otterrà a breve una
risposta e l’invio di messaggi, che possono essere di diverso tipo:
∗ messaggi di testo;
∗ immagini;
∗ video;
∗ messaggi di testo con risposte rapide1 ;
∗ messaggi composti da titolo, sottotitolo, un’immagine e dei bottoni opzionali;
∗ invio di ricevute d’acquisto.
Durante lo sviluppo del bot avere a disposizione diversi tipi di messaggi da poter
inviare si è rivelato molto utile al fine di poter creare una maggiore interazione con
l’utente e ottenere in generale un risultato migliore e più appetibile.
L’applicazione creata è poi stata associata a una pagina di Facebook. In questa
maniera gli utenti, scrivendo alla pagina, mandano il messaggio direttamente al bot
che provvederà poi a rispondergli nella maniera adeguata.
1
Le risposte rapide sono dei bottoni presenti subito sotto il messaggio del bot, che possono
aiutare l’utente perché non è necessario digitare testo per rispondergli, ma è possibile selezionare
una risposta in maniera rapida.2.2. PASTBOT 17
figura 2.11: Logo di Messenger
DashBot
La compagnia ha ritenuto importante raccogliere dati sull’utilizzo del bot per poter
offrire un servizio migliore all’utenza in futuro. Per adempiere a questo obiettivo è
stato deciso di utilizzare la piattaforma web dashbot.io. DashBot è un servizio web
gratuito che mette a disposizione delle API ai programmatori dove poter inviare i
messaggi ricevuti e i messaggi che si ha intenzione di inviare. Una volta inviato il
contenuto del messaggio, il servizio si preoccuperà di analizzarne il contenuto ed
estrapolarne le informazioni sull’utente (nazionalità, sesso, lingua madre) e sul tipo
di contenuto inviato (testo o allegato). In base a questi fattori, è in grado di creare
statistiche riguardo a:
∗ livello di intrattenimento;
∗ ritorno dell’utenza;
∗ numero di messaggi scambiati per utente;
∗ conteggio dei messaggi ricevuti e inviati;
∗ tipo di testo ricevuto;
∗ lunghezza delle sessioni di chat per utente.
I dati vengono poi mostrati tramite diversi tipi di grafici e permette di avere una
visione generale sull’utilizzo del bot e sul suo gradimento.
figura 2.12: Logo di DashBotCapitolo 3
Analisi dei requisiti
PastBot nasce da un insieme di nuove tecnologie e dalla necessità di ampliare i
metodi a disposizione per l’acquisito di prodotti da PastBook. La prima attività
del progetto è stata dunque la consultazione del parere del servizio marketing e del
Chief Executive Officer (CEO) riguardo la creazione di un nuovo modo per interagire
con gli utenti. Dopo che la creazione di un bot per la piattaforma Facebook è stata
accolta, si è passati a valutare l’opinione di una parte dell’utenza di PastBook.
L’utenza ascoltata fa parte del gruppo di tester di PastBook, che ha deciso di avere
un accesso anticipato ai nuovi prodotti in cambio di una loro valutazione. L’azienda
si è rivolta a loro anche per valutare l’interessamento nell’utilizzo di un futuro bot
per Facebook, idea che è stata accolta favorevolmente in buona parte.
Si è quindi passati all’interazione con il reparto di codifica, che ha dovuto eseguire
un’analisi dei requisiti per estrapolare i casi d’uso prima di poter cominciare a
progettare il prodotto.
1920 CAPITOLO 3. ANALISI DEI REQUISITI
3.1 Requisiti di PastBot
PastBot suddivide l’utenza in due categorie principali: l’utenza non registrata,
ovvero che non ha mai scritto al bot e l’utenza registrata, cioè che ha almeno una
volta scritto al bot.
3.1.1 UC0: caso d’uso generale
∗ Attori: Utente Non Autenticato, Utente Autenticato;
∗ Descrizione: un utente innanzitutto deve iniziare la conversazione con il
bot. Dopo di che avrà a disposizione il sistema di conversazione in cui poter
mandare messaggi al bot;
∗ Precondizione: l’utente deve aver un account Messenger e deve averci
effettuato la connessione;
∗ Postcondizione: il sistema ha erogato le funzionalità richieste dall’utente;
∗ Flusso principale:
1. L’Utente Non Autenticato può iniziare una conversazione per la prima
volta in assoluto (UC1)
2. L’Utente Autenticato può inviare una richiesta di creare nuovo album
(UC2)
3. L’Utente Autenticato può inviare una richiesta di visualizzare l’album
esistente (UC3)
4. L’Utente Autenticato può inviare una richiesta riguardante le informa-
zioni sui costi (UC4)
5. L’Utente Autenticato può inviare un comando per ricevere aiuto (UC5)
6. L’Utente Autenticato può inviare una richiesta di visualizzazione dell’al-
bum nel sito web (UC6)
7. L’Utente Autenticato può inviare un comando non valido (UC7)
8. L’Utente Autenticato può inviare uno sticker (UC8)
9. L’Utente Autenticato può inviare un allegato (UC9)
10. L’Utente Autenticato può visualizzare il menù permanente. (UC11)3.1. REQUISITI DI PASTBOT 21
figura 3.1: UC0: caso d’uso generale
3.1.2 UC1: inizio conversazione per la prima volta in asso-
luto
∗ Attori: Utente Non Autenticato;
∗ Descrizione: l’Utente Non Autenticato vuole scrivere al bot per la prima
volta in assoluto. Per fare questa azione dovrà premere il bottone Inizia
presente in Messenger;
∗ Precondizione: l’Utente Non Autenticato è iscritto alla piattaforma di
messaggistica Facebook Messenger;
∗ Postcondizione: l’Utente Non Autenticato ha inviato con successo il suo
primo messaggio al bot;
∗ Flusso principale:22 CAPITOLO 3. ANALISI DEI REQUISITI
1. L’Utente Non Autenticato clicca sul bottone apposito per iniziare la
conversazione
3.1.3 UC2: invio richiesta di creazione di un nuovo album
∗ Attori: Utente Autenticato;
∗ Descrizione: l’Utente Autenticato procede alla richiesta di creazione di un
nuovo album di foto. Gli verrà posta una domanda per avere conferma della
creazione, alla quale potrà rispondere in maniera affermativa o negativa;
∗ Precondizione: l’Utente Autenticato ha cominciato la conversazione con il
bot;
∗ Postcondizione: l’Utente Autenticato ha gestito con successo il proprio
album;
∗ Flusso principale:
1. L’Utente Autenticato può confermare la creazione di un nuovo album
(UC2.1)
2. L’Utente Autenticato può non confermare la creazione di un nuovo album
(UC2.2)
figura 3.2: UC2: invio richiesta di creazione di un nuovo album
3.1.4 UC2.1: risposta affermativa al messaggio di conferma
Creazione nuovo album
∗ Attori: Utente Autenticato;
∗ Descrizione: l’Utente Autenticato conferma la decisione di voler creare un
nuovo album;
∗ Precondizione: l’Utente Autenticato ha richiesto la creazione di un nuovo
album;
∗ Postcondizione: l’Utente Autenticato ha confermato con successo la volontà
di creare un nuovo album;3.1. REQUISITI DI PASTBOT 23
∗ Flusso principale:
1. L’Utente Autenticato conferma positivamente la creazione di un nuovo
album
3.1.5 UC2.2: risposta negativa al messaggio di conferma
Creazione nuovo album
∗ Attori: Utente Autenticato;
∗ Descrizione: l’Utente Autenticato decide di non voler più creare un nuovo
album;
∗ Precondizione: l’Utente Autenticato ha richiesto la creazione di un nuovo
album;
∗ Postcondizione: l’Utente Autenticato ha confermato con successo la volontà
di non procedere alla creazione di un nuovo album;
∗ Flusso principale:
1. L’Utente Autenticato conferma negativamente la creazione di un nuovo
album
3.1.6 UC2.3: creazione di un nuovo album
∗ Attori: Utente Autenticato;
∗ Descrizione: si ottiene un nuovo album vuoto in cui sarà possibile inserire
nuove foto;
∗ Precondizione: l’Utente Autenticato ha confermato positivamente la volontà
di creare un nuovo album;
∗ Postcondizione: l’Utente Autenticato dispone di un nuovo album;
∗ Flusso principale:
1. L’Utente Autenticato ha confermato positivamente la creazione di un
nuovo album24 CAPITOLO 3. ANALISI DEI REQUISITI
3.1.7 UC3: invio richiesta di visualizzazione foto dell’album
attivo
∗ Attori: Utente Autenticato;
∗ Descrizione: l’Utente può richiedere la visualizzazione della lista delle foto
attualmente caricate, su cui può decidere di cancellarne alcune, di visualizzarle
senza perdita di risoluzione o di acquistarle in un album;
∗ Precondizione: l’Utente Autenticato ha cominciato la conversazione con il
bot;
∗ Postcondizione: l’Utente Autenticato ha visualizzato con successo la lista
delle foto presenti nel proprio album;
∗ Flusso principale:
1. L’Utente Autenticato può cancellare una singola foto dall’album (UC3.1)
2. L’Utente Autenticato può visualizzare una singola foto dell’album alla
massima risoluzione disponibile (UC3.2)
3. L’Utente Autenticato può richiedere l’acquisto dell’album (UC3.4)
∗ Scenari alternativi:
1. L’Utente Autenticato richiede la visualizzazione di un album vuoto
(UC12)
figura 3.3: UC3: invio richiesta di visualizzazione foto dell’album attivo
3.1.8 UC12: visualizzazione messaggio di errore album vuo-
to
∗ Attori: Utente Autenticato;
∗ Descrizione: questa situazione avviene quando non sono presenti foto
all’interno dell’album;3.1. REQUISITI DI PASTBOT 25
∗ Precondizione: l’Utente Autenticato ha richiesto la visualizzazione dell’al-
bum vuoto;
∗ Postcondizione: l’Utente Autenticato ha visualizzato con successo il mes-
saggio di errore;
∗ Flusso principale:
1. L’Utente Autenticato richiede la visualizzazione dell’album senza foto-
grafie
3.1.9 UC3.1: cancellazione singola foto
∗ Attori: Utente Autenticato;
∗ Descrizione: l’Utente Autenticato richiede la cancellazione di una foto
dall’album;
∗ Precondizione: l’Utente Autenticato ha la lista delle foto presenti nell’al-
bum;
∗ Postcondizione: l’Utente Autenticato ha rimosso con successo una foto
dall’album;
∗ Flusso principale:
1. L’Utente Autenticato invia la richiesta per rimuovere una foto dall’album
∗ Scenari alternativi:
1. L’Utente Autenticato riceve un messaggio di errore nella cancellazione
della foto (UC3.3)
3.1.10 UC3.2: visualizzazione singola foto nel browser
∗ Attori: Utente Autenticato;
∗ Descrizione: l’Utente Autenticato vuole visualizzare in maniera dettagliata
e con la massima qualità disponibile una foto presente nell’album;
∗ Precondizione: l’Utente Autenticato ha la lista delle foto presenti nell’al-
bum;
∗ Postcondizione: l’Utente Autenticato ha visualizzato con successo una foto
dall’album;
∗ Flusso principale:
1. L’Utente Autenticato visualizza la foto dall’album26 CAPITOLO 3. ANALISI DEI REQUISITI
3.1.11 UC3.3: visualizzazione messaggio di errore cancella-
zione foto
∗ Attori: Utente Autenticato;
∗ Descrizione: questo caso si verifica quando l’Utente Autenticato ordina la
cancellazione di una foto già cancellata o ordina la cancellazione di una foto
di un album non più esistente;
∗ Precondizione: l’Utente Autenticato ha ordinato la cancellazione di una
foto non esistente o già cancellata;
∗ Postcondizione: l’Utente Autenticato ha visualizzato il messaggio di errore
con successo;
∗ Flusso principale:
1. L’Utente Autenticato riceve un messaggio di errore nel tentativo di
cancellare una specifica foto
3.1.12 UC3.4: acquisto album
∗ Attori: Utente Autenticato;
∗ Descrizione: l’utente è soddisfatto dell’album creato e vuole procederne
all’acquisto;
∗ Precondizione: l’Utente Autenticato ha la lista delle foto presenti nell’album
e in quell’album ci sono almeno venti foto;
∗ Postcondizione: l’Utente Autenticato ha acquistato con successo l’album;
∗ Flusso principale:
1. L’Utente Autenticato acquista l’album
∗ Scenari alternativi:
1. L’Utente Autenticato ottiene un messaggio di errore di acquisto album
(UC3.5)
3.1.13 UC3.5: visualizzazione messaggio di errore acquisto
album
∗ Attori: Utente Autenticato;
∗ Descrizione: questo errore avviene quando l’Utente Autenticato tenta di
acquistare un album con meno di venti fotografie;
∗ Precondizione: l’Utente Autenticato ha richiesto l’acquisto dell’album;
∗ Postcondizione: l’Utente Autenticato ha visualizzato il messaggio di errore;3.1. REQUISITI DI PASTBOT 27
∗ Flusso principale:
1. L’Utente Autenticato riceve un messaggio di errore relativo all’impossi-
bilità di effettuare l’acquisto per mancanza di foto
3.1.14 UC4: invio richiesta di informazioni sui costi
∗ Attori: Utente Autenticato;
∗ Descrizione: permette all’Utente Autenticato di avere informazioni riguardo
ai costi degli album e ai relativi costi di spedizione;
∗ Precondizione: L’Utente Autenticato ha cominciato la conversazione con il
bot;
∗ Postcondizione: L’Utente Autenticato ha visualizzato con successo le
informazioni sui costi;
∗ Flusso principale:
1. L’Utente Autenticato richiede le informazioni relative ai costi
3.1.15 UC5: invio comando di aiuto
∗ Attori: Utente Autenticato;
∗ Descrizione: in caso l’Utente Autenticato si trovi in una situazione di
difficoltà e non sappia quale operazione intraprendere, ha la possibilità di
chiedere aiuto per ricevedere delle istruzioni su come utilizzare PastBot;
∗ Precondizione: l’Utente Autenticato ha cominciato la conversazione con il
bot;
∗ Postcondizione: l’Utente Autenticato ha visualizzato con successo le istru-
zioni sull’utilizzo di PastBot;
∗ Flusso principale:
1. L’Utente Autenticato richiede le informazioni sull’utilizzo di PastBot
3.1.16 UC6: invio richiesta di visualizzazione album nel sito
web
∗ Attori: Utente Autenticato;
∗ Descrizione: è possibile visualizzare l’album nel sito web dell’azienda;
∗ Precondizione: l’Utente Autenticato ha cominciato la conversazione con il
bot;
∗ Postcondizione: l’Utente Autenticato viene reindirizzato al sito della com-
pagnia con successo;28 CAPITOLO 3. ANALISI DEI REQUISITI
∗ Flusso principale:
1. l’Utente Autenticato invia la richiesta di visualizzare l’album nel sito
della compagnia
3.1.17 UC7: invio di un comando non valido
∗ Attori: Utente Autenticato;
∗ Descrizione: è possibile che venga inviato un comando non interpretabile
da parte di PastBot. Questo farà mandare a PastBot un messaggio con le
istruzioni e il suo utilizzo;
∗ Precondizione: l’Utente Autenticato ha cominciato la conversazione con il
bot;
∗ Postcondizione: l’Utente Autenticato riceve con successo un messaggio di
aiuto;
∗ Flusso principale:
1. l’Utente Autenticato invia un comando non valido per PastBot
3.1.18 UC8: invio di uno sticker
∗ Attori: Utente Autenticato;
∗ Descrizione: è possibile da parte degli utenti che utilizzano la piattaforma
di messaggistica Messenger inviare anche degli stickers a PastBot;
∗ Precondizione: l’Utente Autenticato ha cominciato la conversazione con il
bot;
∗ Postcondizione: l’Utente Autenticato visualizza con successo la risposta di
PastBot;
∗ Flusso principale:
1. L’Utente Autenticato invia uno sticker
3.1.19 UC9: invio allegato
∗ Attori: Utente Autenticato;
∗ Descrizione: si ha la possibilità di inviare degli allegati a PastBot, per
esempio per poter popolare il proprio album con delle immagini;
∗ Precondizione: l’Utente Autenticato ha cominciato la conversazione con il
bot;
∗ Postcondizione: l’Utente Autenticato visualizza un messaggio di successo
di salvataggio dell’allegato;3.1. REQUISITI DI PASTBOT 29
∗ Flusso principale:
1. L’Utente Autenticato invia un allegato a PastBot
∗ Scenari alternativi:
1. Visualizzazione messaggio di errore per tipo di allegato non valido (UC10)
3.1.20 UC10: visualizzazione messaggio di errore per tipo
di allegato non valido
∗ Attori: Utente Autenticato;
∗ Descrizione: questo messaggio di errore viene visualizzato quando viene
inviato un tipo di allegato che non sia una immagine a PastBot;
∗ Precondizione: l’Utente Autenticato ha cominciato la conversazione con il
bot;
∗ Postcondizione: l’Utente Autenticato visualizza un messaggio di errore con
successo;
∗ Flusso principale:
1. L’Utente Autenticato invia un allegato che non è un’immagine supportata30 CAPITOLO 3. ANALISI DEI REQUISITI
3.1.21 UC11: visualizzazione menù permanente
∗ Attori: Utente Autenticato;
∗ Descrizione: l’Utente Autenticato ha accesso al menù permanente con il
quale può inviare comandi al bot senza doverli inserire tramite la tastiera;
∗ Precondizione: l’Utente Autenticato ha cominciato la conversazione con il
bot;
∗ Postcondizione: l’Utente Autenticato esegue le operazioni desiderate con
successo;
∗ Flusso principale:
1. L’Utente Autenticato può effettuare la richiesta di creazione di un nuovo
album (UC11.1)
2. L’Utente Autenticato può richiedere la visualizzazione delle foto esistenti
nell’ultimo album creato (UC11.2)
3. L’Utente Autenticato può richiedere le informazioni sui prezzi (UC11.4)
4. L’Utente Autenticato può richiedere la visualizzazione del messaggio di
aiuto (UC11.4)
figura 3.4: UC11: visualizzazione menù permanente
3.1.22 UC11.1: creazione di un nuovo album
∗ Attori: Utente Autenticato;
∗ Descrizione: ciò permette all’Utente Autenticato di creare un nuovo album
semplicemente cliccando un bottone;
∗ Precondizione: l’Utente Autenticato ha aperto il menù permanente;
∗ Postcondizione: l’Utente Autenticato ha inviato la richiesta di creazione di
un nuovo album con successo;
∗ Flusso principale:
1. L’Utente Autenticato richiede la creazione di un nuovo album3.1. REQUISITI DI PASTBOT 31
3.1.23 UC11.2: visualizzazione delle foto dell’album esisten-
te
∗ Attori: Utente Autenticato;
∗ Descrizione: tramite questa funzionalità sarà possibile per l’Utente Autenti-
cato visualizzare le foto presenti nell’album in maniera semplice;
∗ Precondizione: l’Utente Autenticato ha aperto il menù permanente;
∗ Postcondizione: l’Utente Autenticato ha inviato la richiesta di visualizza-
zione delle foto di un album esistente con successo;
∗ Flusso principale:
1. L’Utente Autenticato richiede la visualizzazione delle foto di un albumCapitolo 4
Progettazione e codifica
4.1 Progettazione ed implementazione delle API
4.1.1 Descrizione dell’architettura
Dato l’utilizzo dell’architettura serverless, non si è applicato nella scrittura delle
API alcun tipo particolare di pattern. L’architettura di tipo serverless infatti
definisce in modo chiaro la delegazione delle varie responsabilità a componenti
molto piccoli e ben definiti. Questo ha permesso di ottenere tempi di risposta molto
brevi. La parte dedicata alla interazione con gli utenti è stata chiamata webhook a
livello progettuale, per distinguerla dalle API.
4.1.2 Descrizione delle API
Come già accennato nella sezione 2.2.2, le funzionalità più importanti sono state
suddivise in differenti API, ognuna delle quali risiede in una propria istanza di AWS
Lambda.
Comparando questa architettura con un classico pattern MVC1 , queste API
corrisponderebbero al Model, che si occupa di gestire parti della logica della appli-
cazione. Essendo queste parti costituite da una sola responsabilità e con un solo
compito, la loro implementazione si è concretizzata nella realizzazione di una sola
classe per API.
4.2 Descrizione del webhook
La parte dedicata all’interazione con gli utenti è stata realizzata sempre usando
l’architettura serverless, ma essendo la sua complessità maggiore la strutturazione a
classi è stata necessaria al fine di mantenere una facile comprensione del programma
e una buona estendibilità. Tuttavia, per la natura del servizio che PastBot ricopre,
si è scelto di usare una modellazione ad eventi per gestire le richieste provenienti
dalla piattaforma Facebook Messenger. In base agli eventi che vengono gestiti
PastBot si occupa di fare le chiamate alle API corrette. Comparandolo con il
pattern di tipo MVC, webhook si occupa di ricoprire la View e il Controller.
1
Model View Controller
33Puoi anche leggere
