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 Chatbot che fornisca
informazioni legate alla vita aziendale,
provenienti da Customer Relationship
Management o Enterprise Resource
Planning
Tesi di laurea triennale
Relatore
Prof. Mauro Conti
Laureando
Giovanni Sanna
Anno Accademico 2017-2018Giovanni Sanna: Sviluppo di Chatbot che fornisca informazioni legate alla vita aziendale, provenienti da Customer Relationship Management o Enterprise Resource Planning, Tesi di laurea triennale, c Luglio 2018.
Sommario
Il presente documento descrive il lavoro svolto durante il periodo di stage, della
durata di circa trecento ore, dal laureando Giovanni Sanna presso l’azienda Soluzioni
Software S.R.L. Gli obbiettivi da raggiungere erano molteplici.
In primo luogo era richiesto la ricerca e descrizione delle più diffuse piattaforme di
messaggistica che supportano l’utilizzo di chatbot e comparazione delle potenziali
funzionalità offerte da tali piattaforme, tenendo conto anche degli strumenti e tec-
nologie necessarie allo sviluppo del chatbot; alla conclusione dell’analisi, individuare
la piattaforma di messaggistica e l’insieme delle tecnologie con cui sviluppare il
prototipo di chatbot.
In secondo luogo era richiesta l’analisi, progettazione, test e sviluppo di un proto-
tipo di chatbot che reperisse informazioni legate alla vita aziendale, in seguito a
richieste di utenti autorizzati ad accedere a tali informazioni. Un altro obbiettivo
fondamentale riguardava la capacità del chatbot di notificare, ad una lista di utenti
definita, il verificarsi di eventi associati alla realtà aziendale, legati a Customer
Relationship Management o Enterprise Resource Planning.
iiiRingraziamenti
Innanzitutto, vorrei esprimere la mia gratitudine al Prof. Mauro Conti, relatore
della mia tesi, ed alla Dott.ssa Losiouk per l’aiuto e il sostegno fornitomi durante
la stesura del lavoro.
Desidero ringraziare con affetto mia madre per il sostegno, il grande aiuto e per
essermi stata vicino in ogni momento durante gli anni di studio.
Ho desiderio di ringraziare poi i miei amici per tutti i bellissimi anni passati insieme
e le mille avventure vissute.
Padova, Luglio 2018 Giovanni Sanna
vIndice
1 Introduzione 1
1.1 Chatbot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 L’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 L’idea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Organizzazione del testo . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Descrizione dello stage 5
2.1 Introduzione al progetto . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Analisi preventiva dei rischi . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Requisiti e obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Pianificazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Analisi dei requisiti 17
3.1 Casi d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Tracciamento dei requisiti . . . . . . . . . . . . . . . . . . . . . . . 31
4 Progettazione 37
4.1 Tecnologie e strumenti . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2 Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.1 Architettura di alto livello . . . . . . . . . . . . . . . . . . . 39
4.2.2 Architettura di dettaglio . . . . . . . . . . . . . . . . . . . . 40
5 Risultati 47
5.1 Autenticazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2 Nuovo Comando . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3 Comando Generico . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.4 Ottieni fatturato . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6 Verifica e validazione 53
6.1 Verifica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2 Validazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7 Conclusioni 55
7.1 Consuntivo finale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.2 Raggiungimento degli obiettivi . . . . . . . . . . . . . . . . . . . . . 57
7.3 Conoscenze acquisite . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.4 Valutazione personale . . . . . . . . . . . . . . . . . . . . . . . . . . 59
viiviii INDICE 8 Glossario 61
Elenco delle figure
2.1 Pianificazione settimana 13/11/2017 - 17/11/2017 . . . . . . . . . . 9
2.2 Pianificazione settimana 20/11/2017 - 24/11/2017 . . . . . . . . . . 10
2.3 Pianificazione settimana 27/11/2017 - 01/12/2017 . . . . . . . . . . 11
2.4 Pianificazione settimana 04/12/2017 - 08/12/2017 . . . . . . . . . . 12
2.5 Pianificazione settimana 11/12/2017 - 15/12/2017 . . . . . . . . . . 13
2.6 Pianificazione settimana 18/12/2017 - 22/12/2017 . . . . . . . . . . 14
2.7 Pianificazione settimana 08/01/2018 - 12/01/2018 . . . . . . . . . . 15
2.8 Pianificazione settimana 15/01/2018 - 17/01/2018 . . . . . . . . . . 16
3.1 Use Case - UC1: Autenticazione . . . . . . . . . . . . . . . . . . . . 18
3.2 Use Case - UC2: Accesso ai livelli di autorizzazione . . . . . . . . . 19
3.3 Use Case - UC3: Accesso ai comandi . . . . . . . . . . . . . . . . . 20
3.4 Use Case - UC4: Inserimento nuovo utente . . . . . . . . . . . . . . 21
3.5 Use Case - UC5: Rimozione utente . . . . . . . . . . . . . . . . . . 22
3.6 Use Case - UC6: Inserimento nuovo comando . . . . . . . . . . . . 23
3.7 Use Case - UC7: Rimozione comando . . . . . . . . . . . . . . . . . 24
3.8 Use Case - UC8: Inserimento parametro . . . . . . . . . . . . . . . 25
3.9 Use Case - UC9: Associazione comando a livello di autorizzazione . 27
3.10 Use Case - UC10: Associazione utente a livello di autorizzazione . . 28
3.11 Use Case - UC11: Ricerca Item . . . . . . . . . . . . . . . . . . . . 29
3.12 Use Case - UC12: Ottieni fatturato . . . . . . . . . . . . . . . . . . 30
3.13 Use Case - UC13: Visualizzazione dati inseriti . . . . . . . . . . . . 31
4.1 Architettura di alto livello . . . . . . . . . . . . . . . . . . . . . . . 39
4.2 Architettura dettaglio - Main directory . . . . . . . . . . . . . . . . 41
4.3 Architettura dettaglio - Messenger . . . . . . . . . . . . . . . . . . . 42
4.4 Architettura dettaglio - Handler . . . . . . . . . . . . . . . . . . . . 42
4.5 Architettura dettaglio - Service . . . . . . . . . . . . . . . . . . . . 43
4.6 Architettura dettaglio - DBmanager . . . . . . . . . . . . . . . . . . 45
4.7 Architettura dettaglio - Utils . . . . . . . . . . . . . . . . . . . . . . 46
5.1 Autenticazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2 Nuovo comando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.3 Comando generico . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.4 Ottieni fatturato . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
ixx ELENCO DELLE TABELLE
Elenco delle tabelle
3.1 Tabella del tracciamento dei requisti funzionali . . . . . . . . . . . . 32
3.2 Tabella del tracciamento dei requisti funzionali . . . . . . . . . . . . 33
3.3 Tabella del tracciamento dei requisti funzionali . . . . . . . . . . . . 34
3.4 Tabella del tracciamento dei requisti funzionali . . . . . . . . . . . . 35
3.5 Tabella del tracciamento dei requisti funzionali . . . . . . . . . . . . 36
7.1 Consuntivo finale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.2 Raggiungimento obiettivi . . . . . . . . . . . . . . . . . . . . . . . . 58Capitolo 1
Introduzione
1.1 Chatbot
Derivato da chat robot, «chatbot» (o «chat bot») è un programma che simula un
utente umano in una conversazione con un utente reale; esso permette un alto
coinvolgimento, conversazioni attraverso voce e testo, personalizzazione in base al
contesto d’uso, e può essere usato da dispositivi mobili, web browser e popolari
piattaforme chat[g] come Facebook Messenger[g] , Telegram[g] , Skype[g] o Slack[g] .
Con l’avvento delle tecnologie di deep learning[g] come il text-to-speech[g] , ricono-
scimento automatico del discorso, e il processamento del linguaggio naturale, un
chatbot può simulare efficacemente la conversazione umana in contesti come quello
di un call center, servizio clienti telematico o assistenza personale.
Un chatbot è un servizio, governato da regole e a volte da intelligenza artificiale,
che interagisce con un utente attraverso una interfaccia di chat; i servizi offerti
possono variare dall’ambito ludico al business per imprese.
Focalizzandosi sui chatbot a scopo di business, essi permettono di sostituire ope-
ratori umani che normalmente interagiscono telematicamente con i clienti; questa
forma di interazione tende ad essere più veloce e meno invasiva per il cliente. I
chatbots possono avere una conversazione con il cliente imparando dalle risposte di
quest’ultimo, in modo da personalizzare l’interazione offrendo al cliente le rispo-
ste ritenute più adatte in base alle sue preferenze. Questi chatbots sono utili in
molti aspetti dell’esperienza del cliente, come fornire un servizio clienti, presentare
prodotti, effettuare un acquisto, risoluzione dei problemi e coinvolgimento del cliente.
Benefici
I principali benefici nell’uso di un chatbot per un’impresa sono:
∗ Efficienza attraverso l’automazione. Un chatbot può simulare passaggi di
processi complessi e automatizzare compiti comuni e ripetitivi, attraverso
poche e semplici richieste (vocali o testuali), riducendo il tempo di esecuzione
e aumentando l’efficienza del business;
∗ Flessibilità. Un chatbot può essere implementato per rispondere sia con
voce che con testo nella lingua dell’utente; inoltre può essere personalizzato
12 CAPITOLO 1. INTRODUZIONE
e integrato nelle dinamiche aziendali di tutti i giorni, per coinvolgere sia i
dipendenti che i clienti.
∗ Coinvolgimento del cliente. Fornire un’efficace esperienza al cliente è un
fattore chiave nel successo di un business; un chatbot può fornire un supporto
efficace in molti aspetti del rapporto con il cliente. Inoltre, i chatbots possono
essere sviluppati per le principali piattaforme di messaggistica già utilizzate
dai clienti.
Casi d’uso comuni
I più comuni casi d’uso dell’utilizzo di un chatbot sono:
∗ Produttività dell’impresa. I chatbots possono essere integrati in molti aspetti
del business di un’impresa, come la gestione della relazione con il cliente,
gestione del magazzino o gestione dei compiti dei dipendenti; possono es-
sere implementati per controllare il numero delle vendite, prestazioni del
marketing[g] , stato dell’inventario, o prestazioni dei dipendenti;
∗ Assistenza personale. I chatbots possono semplificare e velocizzare il processo
di esecuzione di molte attività personali di ogni giorno, come acquistare un
prodotto, prenotare un appuntamento dal medico o prenotare un viaggio, dal
proprio dispositivo mobile, web browser o applicazione chat preferita;
∗ Applicazioni di call center. I chatbot permettono ai clienti di eseguire com-
piti come il cambio di password, richiedere il bilancio associato al proprio
account o schedulare un appuntamento, senza il bisogno di interagire con un
operatore reale. i chatbot mantengono il contesto del discorso e gestiscono la
conversazione, variando dinamicamente le risposte in base alla conversazione.
1.2 L’azienda
Lo stage si è svolto presso Soluzioni Software SRL, nella sua sede di Padova.
Da quasi 30 anni si occupa di consulenza e sviluppo di software per la gestione
aziendale, utilizzando avanzate e consolidate tecnologie per realizzare soluzioni
complete, flessibili, integrate, aperte ad una costante innovazione e pensate per
essere facilmente implementate nelle differenti realtà aziendali.
L’azienda ha focalizzato i suoi sforzi nello sviluppo di strumenti che potessero
soddisfare i bisogni specifici di diversi settori, facendo fronte alle criticità che chi
opera in queste aree di mercato si trova a dover affrontare quotidianamente; inoltre
garantisce costantemente un servizio di consulenza e supporto tecnico professionale,
per ottimizzare le prestazioni dei prodotti forniti.
Le competenze di base fanno riferimento ai processi ed alle applicazioni delle
aree: ERP[g] , CRM[g] , SCM[g] , PLM[g] , WMS[g] , analytics[g] , e-commerce, internet e
mobile-applications[g] .
I partner con cui Soluzioni Software SRL lavora a stretto contatto sono:
∗ SAP SE: multinazionale europea per la produzione di software gestionale.
È una delle principali aziende al mondo nel settore degli ERP e in generale1.3. L’IDEA 3
nelle soluzioni informatiche per le imprese. Soluzioni Software SRL è partner
SAP[g] per la soluzione SAP Business One, sviluppata per le PMI[g] , in grado
di aiutare le piccole e medie imprese a gestire al meglio ogni aspetto della
loro attività.
∗ Able Tech: software house specializzata nella gestione elettronica dei documen-
ti, del workflow[g] , gestione dei processi aziendali e della conservazione digitale.
La soluzione adottata è ARXivar, una piattaforma modulare, affidabile e
completa per la gestione delle informazioni aziendali (gestione documentale,
workflow e fatturazione elettronica).
1.3 L’idea
Il progetto prevede l’analisi e lo sviluppo di un prototipo[g] di ChatBot che fornisca
informazioni su eventi legati alla vita aziendale provenienti da CRM (Customer
Relationship Management) o ERP (Enterprise Resource Planning). Individuazione
di una piattaforma di messaggistica[g] che supporti i ChatBot e comparazione delle
funzionalità potenziali offerte; successiva realizzazione di un prototipo di ChatBot
che notifichi, ad una lista di utenti definita, eventi associati alla realtà aziendale
derivanti dall’ERP o CRM .
Il progetto prevede l’analisi, test e sviluppo di un prototipo di gestore di messaggi
dall’azienda ai suoi dipendenti utilizzando un ChatBot sviluppato su una delle
piattaforme di messaggistica più note (WeChat[g] , Telegram, Skype Messenger).
Lo studio individuerà una architettura[g] che consentirà la distribuzione dei messaggi
e lo sviluppo di un prototipo che invii informazioni aziendali sia su richieste
parametriche che su evento.
1.4 Organizzazione del testo
Il secondo capitolo approfondisce la descrizione dello stage, iniziando con una
presentazione del progetto per poi riportare l’analisi preventiva dei rischi con
la loro gestione; successivamente vengono descritti sommariamente i requisiti
ed obbiettivi prefissati ed infine viene riportata la pianificazione dettagliata
delle attività nel tempo.
Il terzo capitolo approfondisce la descrizione dei requisiti del prodotto e il loro
tracciamento, classificandoli in base all’importanza della loro implementazione
e al loro tipo (funzionale/qualitativo/di vincolo e obbligatorio/desiderabi-
le/opzionale); inoltre ne vengono illustrati i principali casi d’uso.
Il quarto capitolo descrive inizialmente le tecnologie e strumenti utilizzati nel-
lo sviluppo del prodotto, per poi illustrare e descrivere l’architettura del-
l’applicazione; infine vengono descritte le strategie e tecniche di codifica
adottate.4 CAPITOLO 1. INTRODUZIONE
Il quinto capitolo descrive le metodologie adottate per la verifica e validazione del
prodotto, affinché si abbia una prova concreta dell’affidabilità dell’applicazione
prodotta.
Nel sesto capitolo riporta le conclusioni riguardo il lavoro e l’esperienza di stage,
in termini di rapporto fra le ore preventivate e quelle effettive, rispetto
della pianificazione, raggiungimento degli obbiettivi, conoscenza acquisite e
valutazione finale.
Riguardo la stesura del testo, relativamente al documento sono state adottate le
seguenti convenzioni tipografiche:
∗ gli acronimi, le abbreviazioni e i termini ambigui o di uso non comune menzio-
nati 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 o facenti parti del gergo tecnico sono evidenziati
con il carattere corsivo.Capitolo 2
Descrizione dello stage
Il presente capitolo ha lo scopo di presentare lo stage in termini di strategie di pianifica-
zione adottate per sviluppare il progetto ChatBot ERP CRM, in modo da garantire un
avanzamento controllato mostrando le risorse utilizzate e le tecniche di mitigazione dei
possibili rischi. Inoltre vengono presentati i requisiti e gli obbiettivi prefissati all’inizio
dell’attività di stage.
2.1 Introduzione al progetto
Il progetto consiste essenzialmente nello sviluppo di un prototipo di chatbot che
fornisca informazioni, riguardanti la vita aziendale, ad utenti autenticati e autoriz-
zati ad accedere solo a specifiche informazioni delle aziende di cui sono dipendenti
o clienti. Tali informazioni possono essere reperite in seguito a richieste dell’utente
sotto forma di funzioni previste dal chatbot, il quale gestisce la conversazione per
ottenere eventuali parametri dall’utente necessari al reperimento dell’informazione
voluta; inoltre il chatbot deve prevedere la capacità di notificare, ad una lista
di utenti predefinita, eventi associati alla realtà aziendale provenienti da ERP o
CRM. Il chatbot prevede una sezione di funzioni per amministrare le informazioni
dell’applicazione, come registrare/eliminare un utente o inserire/rimuovere una
funzionalità.
La prima parte del progetto consiste nell’analisi delle principali piattaforme di
messaggistica che supportano l’uso si chatbot: Facebook Messenger, Wechat, Skype
e Telegram; tale analisi si concentra sulle potenzialità delle piattaforme di messag-
gistica in termini di funzionalità implementabili e gestione dell’interfaccia grafica,
oltre che i vincoli e requisiti per lo sviluppo del chatbot nella specifica piattaforma.
Il risultato di tale analisi è l’individuazione di una piattaforma di messaggistica per
cui sviluppare il chatbot.
Successivamente si passa allo studio delle tecnologie e strumenti messi a disposizione
dalla piattaforma per lo sviluppo del prodotto, oltre che all’individuazione delle
procedure necessarie alla pubblicazione del chatbot nella piattaforma scelta. A
tal scopo, vengono implementati due esempi applicativi che mostrino le principali
caratteristiche delle tecnologie adottate e la fattibilità dello sviluppo del chatbot
nella piattaforma scelta.
56 CAPITOLO 2. DESCRIZIONE DELLO STAGE Il progetto continua con la determinazione e classificazione dei requisiti che il prodotto dovrà soddisfare e la definizione di un’architettura che individui tutte le componenti dell’applicazione necessarie a soddisfare i requisiti individuati. Dopodiché si passa alla codifica dei test[g] e del prototipo di chatbot, seguendo quanto prodotto nella progettazione. Infine vengono eseguiti i test e viene effettuato il collaudo del prototipo. 2.2 Analisi preventiva dei rischi Durante la fase di analisi iniziale sono stati individuati alcuni possibili rischi a cui si poteva andare incontro. Si è quindi proceduto a elaborare delle possibili soluzioni per far fronte a tali rischi. Viene inoltre riportato, per ogni rischio individuato, l’effettivo riscontro avuto durante l’attività di stage. 1. Poca familiarità con tecnologie e strumenti adottati Descrizione: l’implementazione del prodotto comporta l’utilizzo di tecnologie e strumenti mai utilizzati, la cui comprensione potrebbe eccedere i tempi previsti. Soluzione: la pianificazione tiene conto di questo fattore, prevedendo un sufficiente numero di ore dedicate allo studio delle tecnologie e strumenti sconosciuti; in caso di difficoltà, si chiede supporto al tutor aziendale. Riscontro: tale rischio si è presentato in maniera contenuta; è stato necessario l’apprendimento di diverse tecnologie e strumenti sconosciuti, i quali hanno richiesto un tempo di auto-formazione leggermente maggiore del previsto, ma senza causare ritardi. 2. Malfunzionamenti hardware o software Descrizione: le attività inerenti allo stage vengono svolte con l’utilizzo di un portatile personale; tali dispositivo è di tipo commerciale e non professionale, quindi è da tenere in considerazione la rottura degli strumenti di lavoro. . Soluzione: l’azienda provvede, in caso di malfunzionamenti degli strumenti dello stagista, a fornire quest’ultimo un personal computer di ricambio su cui lavorare. Riscontro: tale rischio si è presentato, ma grazie alla strumentazione messa a disposizione dall’azienda non si sono subiti ritardi. 3. Stima errata di costi e/o tempi delle attività Descrizione: durante la pianificazione, è probabile che vengano fatte stime sba- gliate sui tempi necessari ad eseguire alcune attività; questo comporterebbe un potenziale ritardo nella consegna . Soluzione: nel stendere il piano delle attività si prevede, per ognuna di esse, un tempo di slack sufficientemente grande da permettere che eventuali sottostime non provochino ritardi inaccettabili. Riscontro: tale rischio si è presentato in maniera contenuta, ma grazie ai tem- po di slack[g] previsti nella stesura della pianificazione, non ha provocato ritardi significativi. 4. Comprensione dei requisiti Descrizione: Durante l’acquisizione e analisi dei requisiti, alcuni di essi potrebbero
2.3. REQUISITI E OBIETTIVI 7
essere fraintesi o compresi solo in parte. Inoltre il dominio del problema potrebbe
essere non capito fino in fondo .
Soluzione: vengono organizzati un numero sufficiente di incontri con il tutor
aziendale, al fine di acquisire, raffinare e/o chiarire i requisiti necessari alla corretta
progettazione del prodotto.
Riscontro: tale rischio si è manifestato in maniera contenuta nelle prime settimane,
ma i meeting[g] settimanali con il tutor aziendale hanno permesso di chiarire i
requisiti richiesti.
2.3 Requisiti e obiettivi
Si farà riferimento ai requisiti secondo le seguenti notazioni:
∗ «ob» per i requisiti obbligatori, vincolanti in quanto obiettivo primario
richiesto dal committente;
∗ «de» per i requisiti desiderabili, non vincolanti o strettamente necessari, ma
dal riconoscibile valore aggiunto;
∗ «op» per i requisiti opzionali, rappresentanti valore aggiunto non strettamente
competitivo.
∗ «for» per gli obiettivi formativi, rappresentanti valore aggiunto in termini
culturali e di conoscenze da acquisire dallo stagista.
Le sigle precedentemente indicate saranno seguite da una coppia sequenziale di
numeri, identificativo del requisito.
Si prevede lo svolgimento dei seguenti obiettivi:
∗ Obbligatori:
– ob01: analisi delle tre piattaforme di messaggistica principali (WeChat,
Telegram, Skype Messenger), individuando potenzialità, punti di forza e
di debolezza;
– ob02: comprensione dell’utilizzo e principali funzionalità delle tecnologie
e strumenti adottati per lo sviluppo del prodotto;
– ob03: definizione dei requisiti che devono essere soddisfatti dal prodotto;
– ob04: creazione di un prototipo il quale fornisca le funzionalità che
soddisfano i requisiti obbligatori;
– ob05: test del prototipo e di tutte le sue funzionalità implementate;
– 0b06: collaudo del prototipo.
∗ Desiderabili:
– de01: ricerca e analisi di ulteriori piattaforme di messaggistica, indivi-
duando potenzialità, punti di forza e di debolezza;8 CAPITOLO 2. DESCRIZIONE DELLO STAGE
– de02: comprensione più avanzata dell’utilizzo e funzionalità delle tecno-
logie e strumenti adottati per lo sviluppo del prodotto;
– de03: integrazione al prototipo delle funzionalità che soddisfano i requisiti
desiderabili e opzionali;
∗ Opzionali:
– op01: studio e analisi di funzionalità basate su intelligenza artificiale che
possono essere integrate al prototipo creato.
∗ Formativi:
– for01: studio e comparazione di piattaforme di messaggistica nell’ambito
di sviluppo di chatbot;
– for02: studio e utilizzo di strumenti e tecnologie per lo sviluppo di
chatbot;
– for03: studio dei sistemi ERP e CRM;
– for04: essere inserito in un contesto operativo dinamico;
– for05: approcciarsi con il mondo del lavoro e sperimentare le dinamiche
aziendali.
2.4 Pianificazione
In questa sezione è riportata la pianificazione, su base settimanale, dei tempi e delle
attività; per ogni settimana, composta di 5 giorni lavorativi da 8 ore ciascuno, è
riportato il diagramma di Gantt[g] con la suddivisione delle attività nel tempo e la
milestone associata alla settimana in oggetto.
Il quantitativo di ore/lavoro totale è risultato essere 304, entro i limiti previsti per
lo stage.2.4. PIANIFICAZIONE 9
Settimana 1 (13/11/2017 - 17/11/2017)
∗ Gantt
Figura 2.1: Pianificazione settimana 13/11/2017 - 17/11/2017
∗ Milestone[g]
Redazione di una breve relazione che descriva la piattaforma di messaggistica
scelta.10 CAPITOLO 2. DESCRIZIONE DELLO STAGE
Settimana 2 (20/11/2017 - 24/11/2017)
∗ Gantt
Figura 2.2: Pianificazione settimana 20/11/2017 - 24/11/2017
∗ Milestone
Implementazione di uno o pù esempi applicativi di utilizzo del framework[g]
scelto per lo sviluppo.2.4. PIANIFICAZIONE 11
Settimana 3 (27/11/2017 - 01/12/2017)
∗ Gantt
Figura 2.3: Pianificazione settimana 27/11/2017 - 01/12/2017
∗ Milestone
Redazione di un documento di analisi dei requisiti per il prototipo.12 CAPITOLO 2. DESCRIZIONE DELLO STAGE
Settimana 4 (04/12/2017 - 08/12/2017)
∗ Gantt
Figura 2.4: Pianificazione settimana 04/12/2017 - 08/12/2017
∗ Milestone
Produzione di un diagramma dell’architettura dettagliata del prototipo.2.4. PIANIFICAZIONE 13
Settimana 5 (11/12/2017 - 15/12/2017)
∗ Gantt
Figura 2.5: Pianificazione settimana 11/12/2017 - 15/12/2017
∗ Milestone
Creazione di un prototipo avente le funzionalità di maggiore interesse.14 CAPITOLO 2. DESCRIZIONE DELLO STAGE
Settimana 6 (18/12/2017 - 22/12/2017)
∗ Gantt
Figura 2.6: Pianificazione settimana 18/12/2017 - 22/12/2017
∗ Milestone
Integrazione al prototipo creato di tutte le funzionalità fissate.2.4. PIANIFICAZIONE 15
Settimana 7 (08/01/2018 - 12/01/2018)
∗ Gantt
Figura 2.7: Pianificazione settimana 08/01/2018 - 12/01/2018
∗ Milestone
Prototipo testato e collaudato.16 CAPITOLO 2. DESCRIZIONE DELLO STAGE
Settimana 8 (15/01/2018 - 17/01/2018)
∗ Gantt
Figura 2.8: Pianificazione settimana 15/01/2018 - 17/01/2018
∗ Milestone
Documentazione del prodotto studiato e dell’applicazione al caso specifico.Capitolo 3
Analisi dei requisiti
Di seguito vengono illustrati i casi d’uso individuati, i quali rappresentano le modalità
d’interazione dell’utente con il sistema; inoltre vengono riportati i requisiti definiti, e
per ognuno di essi il caso d’uso di riferimento.
3.1 Casi d’uso
Per lo studio dei casi di utilizzo del prodotto sono stati creati dei diagrammi. I
diagrammi dei casi d’uso (in inglese Use Case Diagram) sono diagrammi di tipo
UML[g] dedicati alla descrizione delle funzioni o servizi offerti da un sistema, così
come sono percepiti e utilizzati dagli attori che interagiscono col sistema stesso.
Essendo il progetto finalizzato alla creazione di uno strumento per l’automazione
di un processo, le interazioni da parte dell’utilizzatore devono essere ovviamente
ridotte allo stretto necessario. Per questo motivo i diagrammi d’uso risultano
semplici e in numero ridotto.
1718 CAPITOLO 3. ANALISI DEI REQUISITI
UC1: Autenticazione
Attori Principali: Utente non autenticato.
Precondizioni: L’utente non è autenticato ed ha avviato una conversazione con il
Chatbot.
Descrizione:
∗ L’utente inserisce il proprio indirizzo email con cui si è registrato nel sistema;
∗ Se l’indirizzo email inserito è presente nel sistema, quest’ultimo invia una mail
a tale indirizzo contenente un codice di autenticazione, altrimenti visualizza
un messaggio di errore;
∗ L’utente può inserire il codice ricevuto. Se esso è corretto, l’utente effettua
l’accesso alle funzioni del sistema, altrimenti viene visualizzato un messaggio
di errore;
∗ L’utente può chiedere l’invio di un nuovo codice.
Postcondizioni: L’utente è autenticato e può accedere alle funzioni del sistema.
Figura 3.1: Use Case - UC1: Autenticazione3.1. CASI D’USO 19
UC2: Accesso ai livelli di autorizzazione
Attori Principali: Utente autenticato, Utente amministratore.
Precondizioni: L’utente autenticato si è loggato con successo o ha espresso la
volontà di tornare alla sezione principale; l’utente amministratore necessita di
accedere alla lista di tutti i livelli di autorizzazione[g] esistenti.
Descrizione:
∗ L’utente autenticato visualizza la lista dei livelli di autorizzazione a cui può
accedere;
∗ L’utente amministratore visualizza la lista di tutti i livelli di autorizzazione
esistenti;
∗ L’utente autenticato può selezionare un livello di autorizzazione tra quelli
visualizzati;
∗ In caso di selezione errata, viene visualizzato un messaggio d’errore.
Postcondizioni: L’utente ha selezionato un livello di autorizzazione tra quelli
disponibili.
Figura 3.2: Use Case - UC2: Accesso ai livelli di autorizzazione20 CAPITOLO 3. ANALISI DEI REQUISITI
UC3: Accesso ai comandi
Attori Principali: Utente autenticato, Utente amministratore.
Precondizioni: L’utente autenticato ha selezionato un livello di autorizzazione;
l’utente amministratore necessita di accedere alla lista di tutti i comandi[g] esistenti.
Descrizione:
∗ L’utente autenticato visualizza la lista dei comandi associati ad un livello di
autorizzazione;
∗ L’utente amministratore visualizza la lista di tutti i comandi esistenti;
∗ L’utente autenticato può selezionare un comando tra quelli visualizzati;
∗ In caso di selezione errata, viene visualizzato un messaggio d’errore.
∗ L’utente può tornare alla sezione principale
Postcondizioni: L’utente ha selezionato un comando tra quelli disponibili.
Figura 3.3: Use Case - UC3: Accesso ai comandi3.1. CASI D’USO 21
UC4: Inserimento nuovo utente
Attori Principali: Utente amministratore.
Precondizioni: L’utente ha selezionato il comando per inserire un nuovo utente.
Descrizione:
∗ L’utente inserisce l’indirizzo email del nuovo utente. Se tale indirizzo non è
valido o è già presente nel sistema, viene visualizzato un messaggio d’errore;
∗ L’utente inserisce il nome ed il cognome del nuovo utente;
∗ L’utente inserisce il numero di P.IVA[g] dell’azienda da cui il nuovo utente
può estrarre informazioni. Se tale numero non è associato ad una azienda
presente nel sistema, viene visualizzato un messaggio d’errore;
∗ L’utente inserisce l’username per il nuovo utente. Se tale username è già
associato ad un utente presente nel sistema, viene visualizzato un messaggio
d’errore;
∗ Vengono visualizzati i dati inseriti e ne viene richiesta conferma all’utente;
∗ L’utente può annullare l’operazione in qualsiasi momento.
Postcondizioni: L’utente ha inserito con successo un nuovo utente.
Figura 3.4: Use Case - UC4: Inserimento nuovo utente22 CAPITOLO 3. ANALISI DEI REQUISITI
UC5: Rimozione utente
Attori Principali: Utente amministratore.
Precondizioni: L’utente ha selezionato il comando per la rimozione di un utente
presente nel sistema.
Descrizione:
∗ L’utente inserisce l’indirizzo email dell’utente da rimuovere. Se tale indirizzo
non è valido o non è presente nel sistema, viene visualizzato un messaggio
d’errore;
∗ Vengono visualizzati i dati inseriti e ne viene richiesta conferma all’utente;
∗ L’utente può annullare l’operazione in qualsiasi momento.
Postcondizioni: L’utente ha rimosso con successo un utente presente nel sistema.
Figura 3.5: Use Case - UC5: Rimozione utente
UC6: Inserimento nuovo comando
Attori Principali: Utente amministratore.
Precondizioni: L’utente ha selezionato il comando per inserire un nuovo comando.
Descrizione:
∗ L’utente inserisce il nome del nuovo comando. Nel caso tale nome sia già
presente nel sistema o superi i 50 caratteri, viene visualizzato un messaggio
d’errore;3.1. CASI D’USO 23
∗ L’utente inserisce il nome del servizio[g] che gestirà il nuovo comando. In
caso tale nome contenga spazi o superi i 40 caratteri, viene visualizzato un
messaggio d’errore;
∗ L’utente inserisce il numero di parametri da associare al nuovo comando;
∗ L’utente inserisce una descrizione per il nuovo comando;
∗ L’utente può inserire una query[g] da associare al nuovo comando;
∗ L’utente può inserire una stringa di connessione[g] alla base di dati in cui
verrà eseguita la query;
∗ L’utente inserisce gli eventuali parametri da associare al nuovo comando;
∗ Vengono visualizzati i dati inseriti e ne viene richiesta conferma all’utente;
∗ L’utente può annullare l’operazione in qualsiasi momento.
Postcondizioni: L’utente ha inserito con successo un nuovo comando.
Figura 3.6: Use Case - UC6: Inserimento nuovo comando24 CAPITOLO 3. ANALISI DEI REQUISITI
UC7: Rimozione comando
Attori Principali: Utente amministratore.
Precondizioni: L’utente ha selezionato il comando per rimuovere un comando
presente nel sistema.
Descrizione:
∗ L’utente inserisce il nome del comando da rimuovere; Nel caso tale nome
non corrisponda ad un comando presente nel sistema, viene visualizzato un
messaggio d’errore;
∗ L’utente può visualizzare la lista di tutti i comandi presenti nel sistema e
selezionare quelli da rimuovere;
∗ Vengono visualizzati i dati inseriti e ne viene richiesta conferma all’utente;
∗ L’utente può annullare l’operazione in qualsiasi momento.
Postcondizioni: L’utente ha rimosso con successo un comando presente nel sistema.
Figura 3.7: Use Case - UC7: Rimozione comando3.1. CASI D’USO 25
UC8: Inserimento parametro
Attori Principali: Utente amministratore.
Precondizioni: L’utente ha selezionato il comando per inserire un nuovo comando
e durante la sua esecuzione ha espresso la volontà di voler associare uno o più
parametri a tale comando da inserire.
Descrizione:
∗ L’utente inserisce il nome per il parametro;
∗ L’utente inserisce l’etichetta per il parametro;
∗ L’utente seleziona il tipo del parametro;
∗ L’utente può inserire il numero di scelte per il valore che potrà assumere il
parametro;
∗ L’utente inserisce il valore per ogni scelta.
Postcondizioni: L’utente ha associato con successo un parametro al nuovo
comando da inserire.
Figura 3.8: Use Case - UC8: Inserimento parametro26 CAPITOLO 3. ANALISI DEI REQUISITI
UC9: Associazione comando a livello di autorizzazione
Attori Principali: Utente amministratore.
Precondizioni: L’utente ha selezionato il comando per associare un comando
esistente ad un livello di autorizzazione.
Descrizione:
∗ L’utente inserisce il nome del comando da associare; Nel caso tale nome
non corrisponda ad un comando presente nel sistema, viene visualizzato un
messaggio d’errore;
∗ L’utente può visualizzare la lista di tutti i comandi presenti nel sistema e
selezionare quello da associare al livello di autorizzazione;
∗ L’utente inserisce il nome del livello di autorizzazione da associare; Nel
caso tale nome non corrisponda ad un comando presente nel sistema, viene
visualizzato un messaggio d’errore;
∗ L’utente può visualizzare la lista di tutti i livelli di autorizzazione presenti
nel sistema e selezionare quello desiderato;
∗ Vengono visualizzati i dati inseriti e ne viene richiesta conferma all’utente;
∗ L’utente può annullare l’operazione in qualsiasi momento.
Postcondizioni: L’utente ha associato un comando esistente ad un livello di
autorizzazione.3.1. CASI D’USO 27
Figura 3.9: Use Case - UC9: Associazione comando a livello di autorizzazione
UC10: Associazione utente a livello di autorizzazione
Attori Principali: Utente amministratore.
Precondizioni: L’utente ha selezionato il comando per associare un utente esistente
ad un livello di autorizzazione.
Descrizione:
∗ L’utente inserisce l’indirizzo email dell’utente da associare; Nel caso tale
indirizzo non corrisponda ad un utente presente nel sistema, viene visualizzato
un messaggio d’errore;
∗ L’utente inserisce il nome del livello di autorizzazione da associare; Nel
caso tale nome non corrisponda ad un comando presente nel sistema, viene
visualizzato un messaggio d’errore;
∗ L’utente può visualizzare la lista di tutti i livelli di autorizzazione presenti
nel sistema e selezionare quello desiderato;
∗ Vengono visualizzati i dati inseriti e ne viene richiesta conferma all’utente;
∗ L’utente può annullare l’operazione in qualsiasi momento.
Postcondizioni: L’utente ha associato un utente esistente ad un livello di autoriz-
zazione.28 CAPITOLO 3. ANALISI DEI REQUISITI
Figura 3.10: Use Case - UC10: Associazione utente a livello di autorizzazione
UC11: Ricerca Item
Attori Principali: Utente autenticato.
Precondizioni: L’utente ha selezionato il comando per ricercare un item.
Descrizione:
∗ L’utente può selezionare la ricerca in base all’identificativo dell’item[g]
∗ L’utente può selezionare la ricerca in base all’identificativo di un gruppo di
item
∗ L’utente inserisce l’identificativo dell’item che si vuole cercare
∗ L’utente inserisce l’identificativo di un gruppo di items di cui si vuole ottenere
tutti gli items
∗ Vengono visualizzati i dati inseriti e ne viene richiesta conferma all’utente;
∗ Vengono visualizzate le informazioni su ogni item che corrisponde ai criteri di
ricerca inseriti
∗ L’utente può annullare l’operazione in qualsiasi momento.
Postcondizioni: L’utente visualizza le informazioni del/degli eventuali items che
corrispondo ai criteri di ricerca inseriti.3.1. CASI D’USO 29
Figura 3.11: Use Case - UC11: Ricerca Item
UC12: Ottieni fatturato
Attori Principali: Utente autenticato.
Precondizioni: L’utente ha selezionato il comando per ottenere informazioni sul
fatturato compreso tra due date.
Descrizione:
∗ L’utente inserisce la data da cui venga calcolato il fatturato. Nel caso non sia
una data valida, viene visualizzato un messaggio d’errore;
∗ L’utente inserisce la data fino alla quale si vuole calcolare il fatturato. Nel
caso non sia una data valida, viene visualizzato un messaggio d’errore;
∗ Vengono visualizzati i dati inseriti e ne viene richiesta conferma all’utente;
∗ Viene visualizzato il valore del fatturato totale calcolato nel periodo compreso
tra le date in input
∗ Viene visualizzato un grafico delle fatture emesse nel periodo compreso tra le
date in input
∗ L’utente può annullare l’operazione in qualsiasi momento.
Postcondizioni: L’utente visualizza il valore del fatturato compreso all’interno
dell’intervalli di date inserito dall’utente e un grafico relativo allo stesso.30 CAPITOLO 3. ANALISI DEI REQUISITI
Figura 3.12: Use Case - UC12: Ottieni fatturato
UC13: Visualizzazione dati inseriti
Attori Principali: Utente autenticato.
Precondizioni: L’utente sta eseguendo un comando ed ha inserito i valori richiesti.
Descrizione:
∗ Vengono visualizzati i valori inseriti in input dall’utente per il comando che si
sta eseguendo;
∗ L’utente può confermare i dati inseriti;
∗ L’utente può annullare i dati inseriti,
∗ L’utente può riprovare l’esecuzione del comando;
∗ L’utente può ritornare alla sezione principale;
Postcondizioni: L’utente ha visualizzato i valori che ha inserito e li ha confermati
o annullati.
Postcondizioni: L’utene visualizza un messaggio d’errore opportuno.3.2. TRACCIAMENTO DEI REQUISITI 31
Figura 3.13: Use Case - UC13: Visualizzazione dati inseriti
3.2 Tracciamento dei requisiti
Da un’attenta analisi dei requisiti e degli use case effettuata sul progetto è stata
stilata la tabella che traccia i requisiti in rapporto agli use case.
Sono stati individuati diversi tipi di requisiti e si è quindi fatto utilizzo di un codice
identificativo per distinguerli.
Il codice dei requisiti è così strutturato R(F/Q/V)(N/D/O) dove:
R = requisito
F = funzionale
Q = qualitativo
V = di vincolo
N = obbligatorio (necessario)
D = desiderabile
Z = opzionale
Nelle tabelle 3.1, 3.2 e 3.3, 3.4, 3.5 sono riassunti i requisiti e il loro tracciamento
con gli use case delineati in fase di analisi.32 CAPITOLO 3. ANALISI DEI REQUISITI
Tabella 3.1: Tabella del tracciamento dei requisti funzionali
Requisito Descrizione Use Case
RFN-1 Il sistema permette l’autenticazione di un utente UC1
RFN-1.1 L’autenticazione richiede l’inserimento dell’indirizzo UC1.1
email
RFN-1.1.1 Il sistema permette di visualizzare un messaggio di UC1.2
errore in caso di email non valida
RFN-1.1.2 Il sistema permette di visualizzare un messaggio di UC1.2
errore in caso di email non presente nel sistema
RFN-1.2 Il sistema invia un email all’utente con un codice da
usare per l’autenticazione
RFN-1.3 Il sistema permette all’utente di inserire il codice UC1.3
ricevuto
RFN-1.3.1 Il sistema permette di visualizzare un messaggio di UC1.4
errore in caso di codice errato
RFN-1.3.2 Il sistema permette 3 tentativi di inserimento del codice
RFN-1.4 Il sistema permette all’utente di chiedere l’invio di un UC1.5
nuovo codice
RFN-2 Il sistema permette la visualizzazione dei livelli di UC2.1
autorizzazione a cui l’utente può accedere
RFN-2.1 Il sistema permette la selezione di un livello di UC2.3
autorizzazione
RFN-2.2 Il sistema permette di visualizzare un messaggio di UC2.4
errore in caso di selezione errata
RFN-3 Il sistema permette la visualizzazione della lista UC3.1
di comandi associati ad uno specifico livello di
autorizzazione
RFN-3.1 Il sistema permette la selezione di un comando con UC3.3
conseguente avvio dello stesso
RFN-3.2 Il sistema permette di visualizzare un messaggio di UC3.4
errore in caso di selezione errata
RFN-4 Il sistema permette, ad un utente con accesso alle UC4
Funzioni amministrazione sistema, di inserire un nuovo
utente
RFN-4.1 Il sistema richiede di inserire l’indirizzo email del nuovo UC4.1
utente
RFN-4.1.1 Il sistema permette di visualizzare un messaggio di UC4.2
errore in caso di email con formato non valido
RFN-4.1.2 Il sistema permette di visualizzare un messaggio di UC4.2
errore in caso di email associata ad un utente presente
nel sistema
RFN-4.2 Il sistema richiede di inserire nome del nuovo utente UC4.3
RFN-4.3 Il sistema richiede di inserire il cognome del nuovo UC4.3
utente
RFN-4.4 Il sistema richiede di inserire il numero di P.IVA UC4.4
dell’azienda da cui il nuovo utente può estrarre
informazioni
RFN-4.4.1 Il sistema permette di visualizzare un messaggio di Uc4.5
errore in caso di numero di P.IVA non associato ad
alcuna azienda presente nel sistema3.2. TRACCIAMENTO DEI REQUISITI 33
Tabella 3.2: Tabella del tracciamento dei requisti funzionali
Requisito Descrizione Use Case
RFN-4.5 Il sistema richiede di inserire l’username del nuovo UC4.6
utente
RFN-4.5.1 Il sistema permette di visualizzare un messaggio di UC4.7
errore in caso l’username sia associato ad un utente
già presente nel sistema
RFN-4.6 Il sistema mostra le informazioni inserite e ne chiede UC13
conferma all’utente
RFN-4.6.1 In caso non vengano confermate le informazioni UC2 - UC13.4
inserite, il sistema permette all’utente di sceglie-
re se tornare alla sezione principale o riprovare
l’inserimento di un nuovo utente
RFN-4.7 Il sistema permette l’annullamento della procedu-
ra di inserimento di un nuovo utente digitando
AnnullaOperazione
RFN-5 Il sistema permette, ad un utente con accesso alle UC5
Funzioni amministrazione sistema, di rimuovere un
utente presente nel sistema
RFN-5.1 Il sistema di inserire l’indirizzo email dell’utente UC5.1
da rimuovere
RFN-5.1.1 Il sistema permette di visualizzare un messaggio di UC5.2
errore in caso l’indirizzo email non sia associato ad
un utente presente nel sistema
RFN-5.2 Il sistema mostra le informazioni inserite e ne chiede UC13
conferma all’utente
RFN-5.2.1 In caso non vengano confermate le informazioni UC2 - UC13.4
inserite, il sistema permette all’utente di sceglie-
re se tornare alla sezione principale o riprovare
l’inserimento di un nuovo utente
RFN-5.3 Il sistema permette l’annullamento della procedura
di rimozione utente digitando AnnullaOperazione
RFN-6 Il sistema permette, ad un utente con accesso alle UC6
Funzioni amministrazione sistema, di inserire un
nuovo comando nel sistema
RFN-6.1 Il sistema richiede il nome del comando UC6.1
RFN-6.1.1 Il sistema permette di visualizzare un messaggio UC6.3
di errore in caso il nome del comando superi i 50
caratteri
RFN-6.1.2 Il sistema permette di visualizzare un messaggio di UC6.2
errore in caso il nome del comando sia già presente
nel sistema
RFN-6.2 Il sistema richiede il nome del servizio che gestisce UC6.4
il comando
RFN-6.2.1 Il sistema permette di visualizzare un messaggio di UC6.5
errore in caso il nome del servizio contenga spazi o
superi i 40 caratteri
RFN-6.3 Il sistema richiede il numero di parametri da UC6.6
associare al comando
RFN-6.4 Il sistema richiede una descrizione del comando UC6.734 CAPITOLO 3. ANALISI DEI REQUISITI
Tabella 3.3: Tabella del tracciamento dei requisti funzionali
Requisito Descrizione Use Case
RFN-6.5 Il sistema richiede se si vuole associare una query
al comando
RFN-6.5.1 In caso affermativo, il sistema richiede di inserire UC6.8
la query da associare al comando
RFN-6.5.2 In caso affermativo, il sistema richiede di inserire UC6.9
la stringa di connessione alla base di dati in cui
verrà eseguita la query
RFN-6.6 Per ogni parametro da inserire, il sistema ne UC8.1
richiede il nome
RFN-6.7 Per ogni parametro da inserire, il sistema ne UC8.2
richiede l’etichetta (label)
RFN-6.8 Per ogni parametro da inserire, il sistema ne UC8.3
richiede il tipo
RFN-6.8.1 Nel caso il parametro sia di tipo choice, il sistema UC8.4
richiede il numero di scelte
RFN-6.8.1.1 Per ogni scelta, il sistema ne richiede il nome UC8.4
RFN-6.9 Il sistema mostra le informazioni inserite e ne UC13
chiede conferma all’utente
RFN-6.9.1 In caso non vengano confermate le informazioni UC2 - UC13.4
inserite, il sistema permette all’utente di sceglie-
re se tornare alla sezione principale o riprovare
l’inserimento di un nuovo comando
RFN-6.10 Il sistema permette l’annullamento della procedu-
ra di inserimento di un nuovo comando digitando
AnnullaOperazione
RFN-7 Il sistema permette, ad un utente con accesso alle UC7
Funzioni amministrazione sistema, di rimuovere
un comando presente nel sistema
RFN-7.1 Il sistema richiede il nome del comando da UC7.1
rimuovere
RFN-7.1.1 Il sistema permette di visualizzare un messaggio UC7.2
di errore in caso il nome inserito non corrisponda
ad un comando presente
RFN-7.1.1.1 Il sistema permette di visualizzare una lista di UC7.3
comandi tra cui l’utente può selezionare quello da
rimuovere
RFN-7.2 Il sistema mostra le informazioni inserite e ne UC13
chiede conferma all’utente
RFN-7.2.1 In caso non vengano confermate le informazioni UC2 - UC13.4
inserite, il sistema permette all’utente di scegliere
se tornare alla sezione principale o riprovare la
rimozione di un comando
RFN-7.3 Il sistema permette l’annullamento della pro-
cedura di rimozione di un comando digitando
AnnullaOperazione3.2. TRACCIAMENTO DEI REQUISITI 35
Tabella 3.4: Tabella del tracciamento dei requisti funzionali
Requisito Descrizione Use Case
RFN-8 Il sistema permette, ad un utente con accesso alle UC9
Funzioni amministrazione sistema, di associare
un comando ad un livello di autorizzazione
RFN-8.1 Il sistema richiede il nome del comando da UC9.1
associare
RFN-8.1.1 Il sistema permette di visualizzare un messaggio UC9.2
di errore in caso il nome inserito non corrisponda
ad un comando presente
RFN-8.1.1.1 Il sistema permette di visualizzare una lista di UC3
comandi tra cui l’utente può selezionare quello da
associare al livello di autorizzazione
RFN-8.2 il sistema richiede il nome del livello di UC9.3
autorizzazione da associare
RFN-8.2.1 Il sistema permette di visualizzare un messaggio UC9.4
di errore in caso il nome inserito non corrisponda
ad un livello di autorizzazione presente
RFN-8.2.1.1 Il sistema permette di visualizzare una lista UC2
di livelli di autorizzazione tra cui l’utente può
selezionare quello da associare al comando
RFN-8.3 Il sistema mostra le informazioni inserite e ne UC13
chiede conferma all’utente
RFN-8.3.1 In caso non vengano confermate le informazioni UC2 - UC13.4
inserite, il sistema permette all’utente di sceglie-
re se tornare alla sezione principale o riprovare
l’associazione
RFN-8.4 Il sistema permette l’annullamento della procedu-
ra di associazione di un comando con un livello
di autorizzazione digitando AnnullaOperazione
RFN-9 Il sistema permette, ad un utente con accesso alle UC10
Funzioni amministrazione sistema, di associare
un utente ad un livello di autorizzazione
RFN-9.1 Il sistema richiede l’email dell’utente da associare UC10.1
RFN-9.1.1 Il sistema permette di visualizzare un messaggio UC10.2
di errore in caso l’indirizzo email inserito non
corrisponda ad un utente presente
RFN-9.2 il sistema richiede il nome del livello di UC10.3
autorizzazione da associare
RFN-9.2.1 Il sistema permette di visualizzare un messaggio UC10.4
di errore in caso il nome inserito non corrisponda
ad un livello di autorizzazione presente
RFN-9.2.1.1 Il sistema permette di visualizzare una lista UC2
di livelli di autorizzazione tra cui l’utente può
selezionare quello da associare al comando
RFN-9.3 Il sistema mostra le informazioni inserite e ne UC13
chiede conferma all’utente
RFN-9.3.1 In caso non vengano confermate le informazioni UC2 - UC13.4
inserite, il sistema permette all’utente di sceglie-
re se tornare alla sezione principale o riprovare
l’associazione36 CAPITOLO 3. ANALISI DEI REQUISITI
Tabella 3.5: Tabella del tracciamento dei requisti funzionali
Requisito Descrizione Use Case
RFN-9.4 Il sistema permette l’annullamento della procedu-
ra di associazione di un utente con un livello di
autorizzazione digitando AnnullaOperazione
RFN-10 Il sistema permette, ad un utente autenticato, di UC11
effettuare la ricerca di Items
RFN-10.1 Il sistema permette di effettuare la ricerca di un UC11.1
Item in base al suo codice identificativo
RFN-10.2 Il sistema permette di effettuare la ricerca di uno
o più Items in base al codice del gruppo UC11.3
RFN-10.3 Il sistema mostra le informazioni inserite e ne UC13
chiede conferma all’utente
RFN-10.3.1 In caso non vengano confermate le informazioni UC2 - UC13.4
inserite, il sistema permette all’utente di scegliere
se tornare alla sezione principale o riprovare la
ricerca
RFN-10.4 Il sistema permette di visualizzare le informazioni UC11.4
degli Items che corrispondono ai criteri di ricerca
RFN-10.5 Il sistema permette l’annullamento della procedura
di ricerca digitando AnnullaOperazione
RFN-11 Il sistema permette, ad un utente autenticato, di UC12
ottenere il fatturato totale compreso tra due date e
un grafico delle fatture in tale intervallo di tempo
RFN-11.1 Il sistema richiede la data di inizio da cui calcolare UC12.1
il fatturato
RFN-11.1.1 Il sistema permette di visualizzare un messaggio UC12.2
di errore in caso di data di inizio non valida
RFN-11.2 Il sistema richiede la data di fine fino alla quale UC12.3
calcolare il fatturato
RFN-11.2.1 Il sistema permette di visualizzare un messaggio UC12.2
di errore in caso di data di fine non valida
RFN-11.3 Il sistema mostra le informazioni inserite e ne UC13
chiede conferma all’utente
RFN-11.3.1 In caso non vengano confermate le informazioni UC2 - UC13.4
inserite, il sistema permette all’utente di scegliere
se tornare alla sezione principale o riprovare il
comando per l’ottenimento del fatturato
RFN-11.4 Il sistema permette di visualizzare il totale del UC12.4
fatturato compreso tra le date di input
RFN-11.5 Il sistema permette di visualizzare un grafico del- UC12.5
le fatture emesse durante l’intervallo di tempo
compreso tra le date di input
RFN-11.6 Il sistema permette l’annullamento della pro-
cedura di ottenimento del fatturato digitando
AnnullaOperazioneCapitolo 4
Progettazione
In questo capitolo vengono dapprima descritte le tecnologie e strumenti utilizzati nella
realizzazione del prototipo, ed in seguito viene descritta l’architettura, sia ad alto livello
che di dettaglio, di Chatbot ERP CRM.
4.1 Tecnologie e strumenti
Di seguito viene data una panoramica delle tecnologie e strumenti utilizzati.
NodeJS
NodeJS è un framework per realizzare applicazioni Web in Javascript[g] , permettendo
di utilizzare questo linguaggio, tipicamente utilizzato nella “Client-side[g] ”, anche per
la scrittura di applicazioni “server-side[g] ”. La piattaforma è basata sul JavaScript
Engine V8, che è il runtime[g] di Google utilizzato anche da Chrome e disponibile
sulle principali piattaforme, anche se maggiormente performante su sistemi operativi
UNIX-like. La caratteristica principale di Node risiede nella possibilità che offre
di accedere alle risorse del sistema operativo in modalità event-driven[g] : ciò vuol
dire che Node richiede al sistema operativo di ricevere notifiche al verificarsi di
determinati eventi, e rimane quindi in sleep fino alla notifica stessa; solo in tale
momento torna attivo per eseguire le istruzioni previste nella funzione di callback[g] .
Questa tecnologia è stata utilizzata lato server per implementare la logica applicativa
di ChatBot ERP CRM.
Microsoft SQL Server
Microsoft SQL Server è un DBMS[g] relazionale (Relational Database Management
System RDBMS), prodotto da Microsoft; usa una variante del linguaggio SQL
standard (lo standard ISO certificato nel 1992) chiamata Transact-SQL (T-SQL[g] ).
Microsoft SQL Server comunica sulla rete utilizzando un protocollo di livello appli-
cazioni chiamato Tabular Data Stream (TDS[g] ). Microsoft SQL Server supporta
anche Open Database Connectivity (ODBC[g] ).
3738 CAPITOLO 4. PROGETTAZIONE Microsoft BOT Framework Microsoft Bot Framework è un insieme di servizi e strumenti che permettono di creare e gestire applicazioni bot in grado di rispondere all’input degli utenti, espresso in linguaggio naturale. La sua caratteristica principale è di permettere la configurazione di un canale tra il bot e le principali piattaforme di messaggistica, come Facebook Messenger, Telegram, Skype Messenger e anche SMS. Una volta aggiunto il bot ad uno dei servizi offerti, esso è sempre online. BOT Builder SDK BOT Builder SDK è una porzione del framework che fornisce le componenti software necessarie a sviluppare l’applicazione bot in NodeJS. Contiene vari tipi di oggetti usati per creare e modellare la conversazione con l’utente. Ad esempio, fare una domanda e ricevere una risposta di un certo formato o tipo; dare all’utente una lista di opzioni tra cui scegliere; definire il flusso della conversazione come un albero di diversi cammini. Bot Framework Emulator Bot Framework Emulator è uno strumento messo a disposizione dal framework per permettere agli sviluppatori di eseguire e testare il bot senza la necessità che esso sia online o collegato ad una piattaforma di messaggistica. Botbuilder-unit Framework di test per chatbot sviluppati con Microsoft Bot Framework per NodeJS. Supporta sia i test unit che di sistema; esso emula la conversazione tra l’utente e il bot, fornendo input per il bot e validando le risposte. Ogni test richiede in input un array ordinato di passi, in cui ognuno è un messaggio, in formato di stringa, atteso durante la conversazione dall’utente o dal chatbot; inoltre si definisce una logica di validazione per i messaggi. Durante l’esecuzione di un test, viene simulato un dialogo[g] dell’applicazione e ogni messaggio inviato, dall’utente o dal chatbot, viene confrontato con il messaggio atteso in quel momento da uno specifico mittente. Il test fallisce se almeno un messaggio inviato non corrisponde a quanto definito nel test.
Puoi anche leggere
