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
Generazione dinamica di siti pubblici in
WordPress tramite AWS EC2 e Ruby on
Rails
Tesi di laurea triennale
Relatore
Prof.Massimo Marchiori
Laureando
Davide Tognon
Anno Accademico 2018-2019
Davide Tognon: Generazione dinamica di siti pubblici in WordPress tramite AWS EC2 e Ruby on Rails, Tesi di laurea triennale, c Dicembre 2019.
È questione di un attimo e ci si perde davvero.
— Gazebo Penguins - Nebbia
Dedicato a mia madre Roberta.
Sommario
Il presente documento descrive il lavoro svolto durante il periodo di stage, della durata
di circa trecentoventi ore, dal laureando Davide Tognon presso l’azienda Athesys S.r.l.,
con sede a Padova.
Lo scopo principale del progetto era lo sviluppo di un componente software per il
portale cloud MyTemplArt che permetta ad un utente registrato al sistema di generare
dinamicamente un sito WordPress di vetrina delle opere d’arte da lui registrate presso
la piattaforma con un tema predefinito scelto in fase di creazione.
Nel seguente documento verrà illustrato il contesto aziendale di Athesys S.r.l., le
attività svolte durante lo stage per lo sviluppo dell’add-on software e una valutazione
finale dell’esperienza complessiva.
v
“Be the change that you wish to see in the world.”
— Mahatma Gandhi
Ringraziamenti
Innanzitutto, vorrei esprimere la mia gratitudine al Prof. Massimo Marchiori, relatore
della mia tesi, per l’aiuto e il sostegno fornitomi durante la stesura del lavoro.
Desidero ringraziare con affetto i miei parenti per il sostegno, il grande aiuto e per
essermi stati vicini in ogni momento durante gli anni di studio.
Ho desiderio di ringraziare poi i miei amici più cari per tutti i bei momenti passati e
le avventure vissute durante tutti questi anni.
Infine vorrei ringraziare tutti i dipendenti di Athesys S.r.l. per l’ospitalità ricevuta
sin da subito, ma soprattutto vorrei ringraziare il mio tutor Cristian Giusti per la
disponibilità e la fiducia datami durante tutto il periodo di permanenza in azienda.
Padova, Dicembre 2019 Davide Tognon
vii
Indice
1 Introduzione 1
1.1 L’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Servizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2 Prodotti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Organizzazione del testo . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Progetto di stage 5
2.1 Contesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Descrizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1 Obiettivi aziendali . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.2 Obiettivi personali . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Analisi preventiva dei rischi . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Pianificazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Tecnologie e strumenti 9
3.1 Ambiente di sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2 GitLab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.3 Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.4 Ruby on Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.5 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.6 Amazon Elastic Compute Cloud . . . . . . . . . . . . . . . . . 11
3.1.7 WordPress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.8 WordPress Multisite . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.9 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.10 HTML5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.11 CSS3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.12 Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.13 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.14 Haml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Gemme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.1 aws-sdk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.2 httparty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.3 bcrypt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.4 simple_form . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4 Analisi dei requisiti 15
ix
x INDICE
4.1 Attori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Casi d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1 UC0 - Scenario generale . . . . . . . . . . . . . . . . . . . . . . 16
4.2.2 UC1 - Creazione sito . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.3 UC1.1 - Scelta dominio personale . . . . . . . . . . . . . . . . . 18
4.2.4 UC1.2 - Inserimento dominio . . . . . . . . . . . . . . . . . . . 18
4.2.5 UC1.3 - Scelta tema . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.6 UC1.4 - Inserimento email . . . . . . . . . . . . . . . . . . . . . 19
4.2.7 UC1.5 - Inserimento username . . . . . . . . . . . . . . . . . . 19
4.2.8 UC1.6 - Inserimento password . . . . . . . . . . . . . . . . . . . 19
4.2.9 UC1.7 - Conferma creazione . . . . . . . . . . . . . . . . . . . . 20
4.2.10 UC1.8 - Visualizzazione errore . . . . . . . . . . . . . . . . . . 20
4.2.11 UC2 - Visita sito . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.12 UC3 - Visualizzazione informazioni . . . . . . . . . . . . . . . . 21
4.2.13 UC4 - Rimozione sito . . . . . . . . . . . . . . . . . . . . . . . 21
4.3 Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3.1 Requisiti funzionali . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.2 Requisiti qualitativi . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3.3 Requisiti di vincolo . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3.4 Riepilogo dei requisiti . . . . . . . . . . . . . . . . . . . . . . . 24
5 Progettazione e codifica 25
5.1 Architettura generale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2 Architettura add-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.1 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.2 View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.3 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.4 Template WordPress . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.5 Prodotto finale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6 Verifica e validazione 39
6.1 Verifica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.1.1 Analisi statica . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.1.2 Analisi dinamica . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2 Validazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7 Conclusioni 41
7.1 Raggiungimento degli obiettivi . . . . . . . . . . . . . . . . . . . . . . 41
7.1.1 Obiettivi aziendali . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.1.2 Obiettivi personali . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.2 Resoconto dei rischi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.3 Grado di soddisfacimento dei requisiti . . . . . . . . . . . . . . . . . . 42
7.4 Consuntivo finale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.5 Valutazione personale . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Glossario 45
Acronimi 49
Bibliografia 51Elenco delle figure
1.1 Logo di Athesys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Logo di DBManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Logo di Monokee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Logo di MyTemplArt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Logo di Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Logo di GitLab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Logo di Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 Logo di Ruby on Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.5 Logo di Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.6 Logo di Elastic Compute Cloud . . . . . . . . . . . . . . . . . . . . . . 11
3.7 Logo di WordPress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.8 Logo di PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.9 Logo di HTML5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.10 Logo di CSS3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.11 Logo di Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.12 Logo di MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.13 Logo di Haml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1 Use Case - UC0: Scenario generale . . . . . . . . . . . . . . . . . . . . 16
4.2 Use Case - UC1: Creazione sito . . . . . . . . . . . . . . . . . . . . . . 17
5.1 Architettura generale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2 Design pattern Model-View-Controller generale . . . . . . . . . . . . . 26
5.3 Nuove tabelle con relazioni . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4 Pagina iniziale dell’add-on . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.5 Form per la creazione del sito . . . . . . . . . . . . . . . . . . . . . . . 29
5.6 Pagina di informazioni del sito . . . . . . . . . . . . . . . . . . . . . . 30
5.7 Pagina iniziale con gestione sito . . . . . . . . . . . . . . . . . . . . . . 30
5.8 MuseumTheme - Homepage . . . . . . . . . . . . . . . . . . . . . . . . 31
5.9 MuseumTheme - Pagina dell’artista singolo . . . . . . . . . . . . . . . 31
5.10 MuseumTheme - Pagina delle opere d’arte . . . . . . . . . . . . . . . . 32
5.11 MuseumTheme - Pagina dell’opera d’arte singola . . . . . . . . . . . . 32
5.12 MuseumTheme - Pagina delle collezioni . . . . . . . . . . . . . . . . . 33
5.13 MuseumTheme - Pagina delle opere d’arte di una collezione . . . . . . 33
5.14 MuseumTheme - Pagina di 404 . . . . . . . . . . . . . . . . . . . . . . 33
5.15 ArtistTheme - Homepage . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.16 ArtistTheme - Pagina degli artisti . . . . . . . . . . . . . . . . . . . . 34
xi5.17 ArtistTheme - Pagina dell’artista singolo . . . . . . . . . . . . . . . . . 35
5.18 ArtistTheme - Pagina delle opere d’arte . . . . . . . . . . . . . . . . . 35
5.19 ArtistTheme - Pagina dell’opera d’arte singola . . . . . . . . . . . . . 36
5.20 ArtistTheme - Pagina delle collezioni . . . . . . . . . . . . . . . . . . . 36
5.21 ArtistTheme - Pagina delle opere d’arte di una collezione . . . . . . . 37
5.22 ArtistTheme - Pagina di 404 . . . . . . . . . . . . . . . . . . . . . . . 37
Elenco delle tabelle
2.1 Tabella degli obiettivi aziendali . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Analisi dei rischi preventiva . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Pianificazione oraria del periodo di stage . . . . . . . . . . . . . . . . . 8
4.1 Requisiti funzionali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Requisiti qualitativi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3 Requisiti di vincolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.4 Riepilogo dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1 Test di unità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.1 Raggiungimento degli obiettivi . . . . . . . . . . . . . . . . . . . . . . 41
7.2 Resoconto dei rischi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.3 Requisiti soddisfatti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.4 Consultivo finale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
xiiCapitolo 1
Introduzione
In questo capitolo viene presentata, brevemente, l’azienda ospitante, descrivendo i servizi
e i prodotti che essa offre. Verrà successivamente illustrata la suddivisione del testo del
documento e le convenzioni tipografiche utilizzate.
1.1 L’azienda
Figura 1.1: Logo di Athesys
Athesys S.r.l. nasce nel 2010 con sede a Padova dall’unione di affermati professionisti del
settore IT che vantano una vasta esperienza in diversi ambiti tecnologici con l’obiettivo
di mettere a fattor comune la loro competenza e tradurla nella capacità di erogare
consulenza ad elevato contenuto tecnologico e progettuale a supporto delle complesse
scelte strategiche che le aziende sono chiamate a prendere. I valori su cui l’azienda
si basa sono l’autonomia nel prendere decisioni, la creatività, l’apertura mentale e la
curiosità verso le nuove tecnologie. Athesys lavora presso importanti realtà aziendali
operanti nel settore bancario, pubblico e automotive.
1.1.1 Servizi
Sicurezza
Athesys mette a servizio le proprie competenze tecniche e progettuali, applicate alle
tecnologie leader del mercato, per la definizione della strategia di sicurezza aziendale. La
missione è quella di salvaguardare la conservazione dei dati, gestire la loro esposizione,
adeguare le authentication policies al GDPR per tutelare il business delle aziende
clienti e quello degli stakeholders.
12 CAPITOLO 1. INTRODUZIONE
DBMS
L’azienda mette a disposizione un servizio di Database Management System (DBMS)
per supportare i propri clienti nella gestione dell’intero ciclo di vita del database,
aiutando a renderlo scalabile e sicuro.
Cloud
Athesys vuole dare valore aggiunto al business dei propri clienti utilizzando il cloud
come strumento da affiancare e/o sostituire all’infrastruttura IT, abbattendo i costi di
gestione e ottimizzando la sicurezza del dato.
1.1.2 Prodotti
DBManager
DBManager agevola il Database Administrator (DBA) nella gestione delle operazioni
quotidiane mediante tool di automazione non presenti nativamente nella suite Micro-
soft SQL Server. Aiuta ad utilizzare a pieno le risorse hardware messe a disposizione,
evitando l’acquisto di server più potenti.
Figura 1.2: Logo di DBManager
DBManager offre:
• Controllo totale di tutte le operazioni di manutenzione, backup e aggiornamento
delle basi di dati;
• Ottimizzazione dell’utilizzo delle risorse hardware in base alle esigenze operative
specifiche;
• Ottimizzazione e riduzione dei tempi di esecuzione delle attività di routine da
parte dei DBA;
• Capacità di intervenire solo quando e dove serve grazie al sistema di notifiche
automatiche via email relative ad attività pianificate e soglie di utilizzo delle
risorse;
• Controllo sulle modifiche alle strutture dati (tabelle, indici, etc.) e sull’o-
peratività corrente, per poter individuare in tempi rapidi eventuali cause di
malfunzionamenti applicativi.1.2. ORGANIZZAZIONE DEL TESTO 3
Monokee
Monokee è una completa e personalizzabile soluzione di Identity and Access Management
(IAM) come servizio che rende il business aziendale più sicuro, assicurando la protezione
delle identità digitali e dei dispositivi intelligenti.
Fornisce un accesso intelligente a dipendenti e stakeholders per connettersi in modo
sicuro a dati, dispositivi, applicazioni e Application Program Interface (API) aziendali.
Monokee aiuta a prevenire violazioni della sicurezza, gestire i dati sensibili e alleggerire
l’operatività connessa al ciclo di vita degli utenti. Infatti, Monokee può aiutare a snellire
l’impegno del comparto IT dell’azienda e ad aumentare la produttività ottimizzando
l’equilibrio tra sicurezza e praticità.
Figura 1.3: Logo di Monokee
Monokee offre funzionalità per la sicurezza del login, tra cui:
• Single Sign-On: consente all’utente di autenticarsi una sola volta e di avere
accesso a tutte le risorse aziendali alle quali è abilitato;
• Autenticazione a due fattori: aggiunge un ulteriore livello di sicurezza e
rende più difficile agli intrusi l’accesso ai dispositivi e agli account online, in
quanto viene richiesta un’ulteriore verifica da un dispositivo fisico dell’utente.
1.2 Organizzazione del testo
Il secondo capitolo descrive il progetto di stage e gli obiettivi, i rischi e la pianifica-
zione ad esso associati.
Il terzo capitolo approfondisce le tecnologie e gli strumenti utilizzati per la proget-
tazione del componente software sviluppato.
Nel quarto capitolo vengono descritti i casi d’uso del sistema e i corrispondenti
requisiti individuati durante la fase di analisi dei requisiti.
Il quinto capitolo descrive i dettagli implementativi del progetto.
Il sesto capitolo descrive i processi di verifica e validazione attuati nel progetto.
Nel settimo capitolo, infine, è riassunto il lavoro svolto e i risultati raggiunti.4 CAPITOLO 1. INTRODUZIONE
Riguardo la stesura del testo, sono state adottate le seguenti convenzioni tipografiche:
• Gli acronimi, le abbreviazioni e i termini ambigui o di uso non comune menzionati
vengono definiti nel glossario, situato alla fine del presente documento;
• Le parole presenti nel glossario sono in colore blu soltanto nella loro prima
occorrenza.Capitolo 2
Progetto di stage
Lo stage per uno studente di Laurea Triennale in Informatica dell’Università di Padova
rappresenta l’atto conclusivo della sua carriera universitaria. Lo stage è stato proposto
durante l’incontro STAGE-IT, organizzato dall’Università, svoltosi il 03 aprile 2019. In
questo capitolo viene descritto il progetto proposto, insieme agli obiettivi, i rischi ad esso
associati e la pianificazione oraria delle otto settimane di permanenza in azienda.
2.1 Contesto
MyTemplArt è una soluzione web e mobile di gestione di patrimoni artistico-culturali
di enti pubblici e privati in cloud.
Figura 2.1: Logo di MyTemplArt
Il portale permette:
• La creazione e manutenzione di un complesso archivio che raccoglie il ciclo di
vita di ogni singola opera d’arte;
• L’aggiornamento continuo dell’anagrafica degli autori;
• La gestione e il coordinamento per allestire gallerie e/o musei;
• L’implementazione di misure per la tutela e anticontraffazione dei certificati di
autenticità.
Obiettivo di MyTemplArt è mappare le esigenze contemporanee di catalogazione e
certificazione delle opere, sempre in continua evoluzione, arricchendosi di spunti e
innovazioni per fornire risposte concrete alle esigenze del settore.
MyTemplArt è stato sviluppato da Artechne S.r.l., una start-up di innovazione tec-
nologica nata nel luglio 2013 con sede a Verona che ha come finalità la tutela e la
56 CAPITOLO 2. PROGETTO DI STAGE
diffusione dell’arte nel panorama internazionale. Athesys si occupa della manutenzione,
contribuendo anche allo sviluppo di nuove funzionalità.
2.2 Descrizione
Il progetto di stage proposto consiste nella realizzazione di un add-on software da
integrare a MyTemplArt. Tale componente permetterà agli iscritti di pubblicare
dinamicamente siti in WordPress a partire da un numero predeterminato di temi e
popolato interrogando le API pubbliche di MyTemplArt. I siti WordPress renderanno
pubblicamente fruibili le opere e gli artisti censiti da ogni account nella sua area privata.
Le istanze di WordPress saranno in hosting presso l’infrastruttura di Amazon Web
Services.
2.3 Obiettivi
2.3.1 Obiettivi aziendali
Gli obiettivi dello stage fanno riferimento alla seguente notazione:
• O per i requisiti obbligatori, vincolanti in quanto obiettivo primario richiesto
dall’azienda;
• D per i requisiti desiderabili, non strettamente necessari ma dal riconoscibile
valore aggiunto.
Gli obiettivi sono seguiti da un numero che li identifica univocamente.
Codice Descrizione
O-01 Realizzazione di un nuovo add-on per MyTemplArt
Realizzazione di un componente che genera dinamicamente siti pubblici
O-02
in WordPress
O-03 Gestione di un numero di siti tramite WordPress Multisite
O-04 Realizzazione di un componente che interroga le API di MyTemplArt
O-05 Realizzazione di templates WordPress
Tabella 2.1: Tabella degli obiettivi aziendali
2.3.2 Obiettivi personali
Lo stage è stata la mia prima esperienza lavorativa in un’azienda informatica. Per-
sonalmente mi interessava comprendere come funzionasse il processo di sviluppo di
un progetto all’interno di una realtà aziendale. Inoltre ero interessato a mettere alla
prova le mie capacità di comprensione del codice scritto da altri programmatori, in
modo da poterlo espandere. Infine, volevo arricchire le mie conoscenze tecniche con
nuovi linguaggi di programmazione e framework a me sconosciuti, come Ruby, Ruby
on Rails e la piattaforma Docker.2.5. PIANIFICAZIONE 7
2.4 Analisi preventiva dei rischi
Durante la fase iniziale sono stati individuati alcuni possibili rischi e le rispettive
contromisure da adottare per mitigarli. Tali rischi sono raggruppati nella tabella 2.2
dove è presente la descrizione del rischio, la sua probabilità di occorrenza, il suo grado
di pericolosità e le contromisure da adottare nel caso esso si presenti.
Rischio Descrizione Grado Contromisure
Chiedere chiarimenti al tu-
Il tempo richiesto per l’ap- Occorrenza:
tor aziendale sulle nuo-
Difficoltà tec- prendimento delle nuove Media
ve tecnologie che stanno
nologiche tecnologie potrebbe causa- Pericolosità:
rallentando l’avanzamento
re ritardi nello sviluppo Alta
del progetto
I servizi di terze parti po- Segnalare e analizzare il
Occorrenza:
trebbero non offrire il ser- problema con il tutor
Difficoltà di Bassa
vizio richiesto oppure le aziendale in modo da tro-
realizzazione Pericolosità:
funzionalità sono troppo vare una nuova soluzione
Alta
complesse alternativa
Avvisare il tutor nel caso
Lo sviluppo del progetto Occorrenza: in cui avvengano rallenta-
Difficoltà di stage potrebbe non fini- Media menti rispetto al piano di
tempistiche re nel periodo pianificato a Pericolosità: lavoro prefissato e aggior-
causa di ritardi Alta nare tale pianificazione di
conseguenza
Durante il periodo di sta-
Occorrenza:
ge è possibile che avvenga- Pianificare il lavoro in mo-
Impegni per- Bassa
no assenze dovute a pro- do da avere giorni per
sonali Pericolosità:
blemi di salute o impegni recuperare le assenze
Bassa
personali
Tabella 2.2: Analisi dei rischi preventiva
2.5 Pianificazione
In accordo con l’azienda, il periodo di stage è stato programmato con data di inizio il
28 agosto 2019 e fine il 22 ottobre 2019, per un totale di 8 settimane, ovvero 320 ore.
Vengono riportate nella tabella 2.3 in dettaglio le attività previste, specificando il
numero di ore preventivate e il periodo in cui ne è stato pianificato lo svolgimento.
Ore Descrizione attività Periodo
40 Studio delle tecnologie coinvolte nel progetto 28/08 - 03/09
32 Identificazione e creazione dei templates di sito 04/09 - 09/09
16 Studio dell’architettura di MyTemplArt 10/09 - 11/09
Continua nella pagina successiva8 CAPITOLO 2. PROGETTO DI STAGE
Continua dalla pagina precedente
Ore Descrizione attività Periodo
96 Modifiche a MyTemplArt 12/09 - 27/09
72 Sviluppo del servizio di generazione di siti pubblici 30/09 - 10/10
8 Preparazione dell’immagine di AWS EC2 11/10 - 11/10
Sviluppo componente client per WordPress che
32 14/10 - 17/10
interroga MyTemplArt
24 Collaudo 18/10 - 22/10
Totale ore: 320
Tabella 2.3: Pianificazione oraria del periodo di stageCapitolo 3
Tecnologie e strumenti
In questo capitolo vengono elencati e descritti gli strumenti, le tecnologie e i pacchetti
(gemme) utilizzati durante lo sviluppo del progetto di stage. La realizzazione dell’add-on
per MyTemplArt ha permesso di apprendere nuove tecnologie e approfondirne alcune in
parte già conosciute. La maggior parte di queste sono state imposte dal tutor aziendale o
dal dominio del problema.
3.1 Ambiente di sviluppo
3.1.1 Git
Figura 3.1: Logo di Git
Software open source per il controllo di versione distribuito per tener traccia delle
modifiche al codice sorgente durante lo sviluppo del software. È progettato per
coordinare il lavoro tra i programmatori, ma può essere utilizzato per tenere traccia
delle modifiche in qualsiasi set di file. I suoi obiettivi includono velocità, integrità dei
dati e supporto per flussi di lavoro distribuiti e non lineari.
3.1.2 GitLab
Strumento di hosting per progetti software che implementa il software di controllo di
versione distribuito Git. Fornisce funzionalità di wiki, tracciamento dei problemi e
pipeline di integrazione continua, usando una licenza open source.
3.1.3 Ruby
Linguaggio di programmazione interpretato e ad alto livello. Ruby è dinamicamen-
te tipizzato e supporta molteplici paradigmi di programmazione, comprese quella
procedurale, orientata agli oggetti e funzionale.
910 CAPITOLO 3. TECNOLOGIE E STRUMENTI
Figura 3.2: Logo di GitLab
Figura 3.3: Logo di Ruby
3.1.4 Ruby on Rails
Figura 3.4: Logo di Ruby on Rails
Framework per applicazioni web lato server scritto in Ruby. Rails utilizza il design pat-
tern Model-View-Controller (MVC), che fornisce strutture predefinite per un database,
un servizio web e pagine web. Incoraggia e facilita l’uso di standard web come JSON o
XML per il trasferimento di dati e HTML, CSS e JavaScript per l’interfaccia utente.
3.1.5 Docker
Figura 3.5: Logo di Docker3.1. AMBIENTE DI SVILUPPO 11
Insieme di prodotti Platform-as-a-Service (PaaS) che utilizzano la virtualizzazione a
livello di sistema operativo per distribuire software in pacchetti chiamati container
(contenitori). Tutti i container sono gestiti da un singolo kernel del sistema operativo e
sono quindi più leggeri delle macchine virtuali.
3.1.6 Amazon Elastic Compute Cloud
Figura 3.6: Logo di Elastic Compute Cloud
Amazon Elastic Compute Cloud (EC2) consente agli utenti di noleggiare computer
virtuali su cui eseguire le proprie applicazioni. EC2 incoraggia l’implementazione
scalabile di applicazioni fornendo un servizio web attraverso il quale un utente può
avviare una Amazon Machine Image (AMI) per configurare una macchina virtuale,
chiamata istanza, contenente qualsiasi software desiderato. Un utente può creare,
avviare e terminare le istanze del server in base alle esigenze.
3.1.7 WordPress
Figura 3.7: Logo di WordPress
Sistema di gestione dei contenuti (CMS) basato su PHP e MySQL. Tra le funzionalità
che offre è presente un’architettura di plugin e un sistema di template, denominati
Temi. WordPress è maggiormente associato ai blog (il suo scopo originale quando è
stato creato) ma si è evoluto per supportare altre tipologie di contenuti web, tra cui
forum, gallerie multimediali e negozi online.12 CAPITOLO 3. TECNOLOGIE E STRUMENTI
3.1.8 WordPress Multisite
Funzionalità di WordPress che permette la creazione e la gestione diversi siti o blog
utilizzando un’unica installazione di WordPress. Tutti i siti condividono i file principali
del CMS e hanno in comune anche temi, plugin e database.
3.1.9 PHP
Figura 3.8: Logo di PHP
Linguaggio di scripting interpretato, originariamente concepito per la programmazione
di pagine web dinamiche. Il codice PHP può essere eseguito con un’interfaccia a riga di
comando, incorporato nel codice HTML o utilizzato in combinazione con vari sistemi
di modelli web, sistemi di gestione dei contenuti e framework.
3.1.10 HTML5
Figura 3.9: Logo di HTML5
Linguaggio di markup per documenti che verranno visualizzati dal browser web. HTML5
è la quinta e attuale versione di HTML e include XHTML.
3.1.11 CSS3
Linguaggio di fogli di stile utilizzato per descrivere la presentazione di un documento
scritto in un linguaggio di markup come HTML. CSS3 è la terza e attuale versione di
CSS.
3.1.12 Bootstrap
Framework CSS open source rivolto allo sviluppo di front end. Contiene modelli di
progettazione basati su CSS e JavaScript per la tipografia, i moduli, i pulsanti, la barra
di navigazione e altri componenti dell’interfaccia.3.1. AMBIENTE DI SVILUPPO 13
Figura 3.10: Logo di CSS3
Figura 3.11: Logo di Bootstrap
3.1.13 MySQL
Figura 3.12: Logo di MySQL
Sistema di gestione di database relazionali open source (RDBMS) composto da un
client a riga di comando e un server.
3.1.14 Haml
Figura 3.13: Logo di Haml
Sistema di template progettato per evitare di scrivere codice inline in un documento
web e rendere HTML più pulito. Haml offre la flessibilità di avere alcuni contenuti
dinamici in HTML.14 CAPITOLO 3. TECNOLOGIE E STRUMENTI 3.2 Gemme In Ruby i pacchetti sono chiamati gemme (gem) e possono essere facilmente installate tramite linea di comando. Di seguito verranno elencate le gemme utilizzate in fase di codifica. 3.2.1 aws-sdk Fornisce interfacce orientate alle risorse e client API per i servizi AWS. Questa gemma è stata utilizzata per la gestione delle istanze di AWS EC2. 3.2.2 httparty httparty semplifica le chiamate HTTP. Questa gemma è stata utilizzata per effettuare le GET request alle API di MyTemplArt. 3.2.3 bcrypt bcrypt fornisce un metodo di crittografia per mascherare le stringhe. Questa gemma è stata utilizzata per cifrare le password da salvare nel database, rendendole più sicure. 3.2.4 simple_form Permette di semplificare la creazione di moduli con Rails. Questa gemma è stata utilizzata per creare i moduli per l’inserimento dei dati per la creazione del sito.
Capitolo 4
Analisi dei requisiti
In questo capitolo vengono descritti i casi d’uso e i requisiti relativi allo sviluppo dell’add-on
per MyTemplArt. Essi sono stati indivuduati da:
• Un’analisi del piano di lavoro;
• Una riunione con il tutor aziendale dove sono stati perfezionati;
• Uno studio dei dati presenti nel portale.
I casi d’uso sono associati ad un diagramma UML 2.0 che riporta lo stesso codice identifi-
cativo e titolo del caso d’uso al quale si riferisce.
4.1 Attori
Lo scopo dell’add-on è fornire agli utenti di MyTemplArt la possibilità di creare un
sito pubblico per esporre le proprie opere presenti nel portale. Gli utilizzatori finali
di MyTemplArt sono quindi i collezionisti privati, gli artisti che vogliono esporre le
proprie opere oppure i musei. L’accesso al portale e alle sue funzionalità è consentito
solamente agli utenti provvisti di credenziali di accesso, fornite durante la registrazione.
L’attore primario individuato è:
• Utente autenticato: utente che ha effettuato l’accesso al sistema e che può
usufruire di tutte le sue funzionalità, compresa quella fornita dall’add-on svilup-
pato.
Inoltre è presente un attore secondario, WordPress, che fornisce il servizio di creazione
e rimozione del sito web.
4.2 Casi d’uso
Ogni caso d’uso è classificato secondo la seguente convenzione:
UC[XX].[YY]
dove:
1516 CAPITOLO 4. ANALISI DEI REQUISITI
• UC: sta per Use Case (inglese per caso d’uso);
• XX: numero che identifica i casi d’uso;
• YY: numero progressivo che identifica i sotto casi.
Ogni caso d’uso viene descritto dalla seguente struttura:
• Attori: lista di attori primari e secondari coinvolti nel caso d’uso;
• Descrizione: breve descrizione generale del caso d’uso;
• Pre-condizione: condizioni che devono essere verificate prima dell’esecuzione
del caso d’uso;
• Post-condizione: condizioni che devono essere verificate dopo l’esecuzione del
caso d’uso;
• Scenario principale: descrizione composta del flusso dei sotto casi del caso
d’uso principale;
• Scenario alternativo: aumento delle funzionalità del caso d’uso. Ogni istanza
del caso d’uso esegue un altro caso d’uso in modo condizionato.
4.2.1 UC0 - Scenario generale
Figura 4.1: Use Case - UC0: Scenario generale
• Attore primario: Utente autenticato;
• Attore secondario: WordPress;
• Descrizione: L’utente autenticato potrà creare il suo sito, visitarlo, visualizzare
le informazioni del sito creato oppure cancellarlo;4.2. CASI D’USO 17
• Pre-condizione: L’utente deve essere autenticato al sistema;
• Post-condizione: L’utente ha scelto l’azione da eseguire;
• Scenario principale:
1. L’attore può creare un sito web con le sue opere presenti su MyTemplArt
(UC1);
2. L’attore può visitare il sito da lui creato (UC2);
3. L’attore può visualizzare le informazioni generali del suo sito web (UC3);
4. L’attore può rimuovere il sito da lui creato (UC4).
4.2.2 UC1 - Creazione sito
Figura 4.2: Use Case - UC1: Creazione sito
• Attore primario: Utente autenticato;
• Attore secondario: WordPress;
• Descrizione: L’utente autenticato potrà inserire le informazioni per creare il sito
e un account WordPress. In caso di errore nella configurazione verrà segnalato a
video l’errore;
• Pre-condizione: L’utente non ha ancora creato un sito web;18 CAPITOLO 4. ANALISI DEI REQUISITI
• Post-condizione: Il sito è stato creato;
• Scenario principale:
1. L’attore può scegliere se utilizzare un proprio dominio personale (UC1.1);
2. L’attore può inserire il proprio dominio o il nome del sottodominio che vuole
utilizzare (UC1,2);
3. L’attore può scegliere il tema del sito tra quelli presenti nel sistema (UC1.3);
4. L’attore può inserire la mail per l’account WordPress (UC1.4);
5. L’attore può inserire l’username per l’account WordPress (UC1.5);
6. L’attore può inserire la password per l’account WordPress (UC1.6);
7. L’attore può confermare la creazione del sito (UC1.7).
• Scenario alternativo: Verrà visualizzato un errore a video se i dati della
configurazione del sito sono errati (UC1.8).
4.2.3 UC1.1 - Scelta dominio personale
• Attore primario: Utente autenticato;
• Descrizione: L’utente autenticato potrà scegliere se utilizzare un dominio
personale oppure se utilizzare il dominio di terzo livello offerto da MyTemplArt;
• Pre-condizione: L’utente vuole scegliere se utilizzare un proprio dominio
personale;
• Post-condizione: L’utente ha scelto;
• Scenario principale:
1. L’attore può scegliere se utilizzare un proprio dominio personale oppure un
sottodominio offerto da MyTemplArt.
4.2.4 UC1.2 - Inserimento dominio
• Attore primario: Utente autenticato;
• Descrizione: L’utente autenticato potrà inserire il nome del proprio dominio o
del sottodominio;
• Pre-condizione: L’utente vuole inserire il nome del dominio o sottodominio;
• Post-condizione: Il nome del dominio o sottodominio è stato inserito;
• Scenario principale:
1. L’attore può inserire il nome del proprio dominio o del sottodominio che
vuole utilizzare per il sito.4.2. CASI D’USO 19
4.2.5 UC1.3 - Scelta tema
• Attore primario: Utente autenticato;
• Descrizione: L’utente autenticato potrà scegliere il tema del sito tra quelli
presenti;
• Pre-condizione: L’utente vuole scegliere un tema;
• Post-condizione: Il tema è stato scelto correttamente;
• Scenario principale:
1. L’attore può scegliere il tema del sito tra quelli messi a disposizione dall’add-
on.
4.2.6 UC1.4 - Inserimento email
• Attore primario: Utente autenticato;
• Descrizione: L’utente autenticato potrà inserire l’email per l’account Word-
Press;
• Pre-condizione: L’utente vuole inserire l’email;
• Post-condizione: L’email è stata inserita;
• Scenario principale:
1. L’attore può inserire l’email per l’account WordPress che verrà creato alla
creazione del sito.
4.2.7 UC1.5 - Inserimento username
• Attore primario: Utente autenticato;
• Descrizione: L’utente autenticato potrà inserire l’username per l’account
WordPress;
• Pre-condizione: L’utente vuole inserire l’username;
• Post-condizione: L’username è stata inserita;
• Scenario principale:
1. L’attore può inserire l’username per l’account WordPress che verrà creato
alla creazione del sito.
4.2.8 UC1.6 - Inserimento password
• Attore primario: Utente autenticato;
• Descrizione: L’utente autenticato potrà inserire la password per l’account
WordPress;
• Pre-condizione: L’utente vuole inserire la password;20 CAPITOLO 4. ANALISI DEI REQUISITI
• Post-condizione: La password è stata inserita;
• Scenario principale:
1. L’attore può inserire la password per l’account WordPress che verrà creato
alla creazione del sito.
4.2.9 UC1.7 - Conferma creazione
• Attore primario: Utente autenticato;
• Attore secondario: WordPress;
• Descrizione: L’utente autenticato può confermare la creazione del sito che verrà
creato in WordPress;
• Pre-condizione: L’utente ha finito la configurazione e vuole confermare la
creazione del sito;
• Post-condizione: L’utente ha confermato la creazione del sito;
• Scenario principale:
1. L’attore può confermare la creazione del sito.
• Scenario alternativo: Se sono presenti errori in fase di configurazione verranno
segnalati a video e il sito non verrà creato (UC1.8).
4.2.10 UC1.8 - Visualizzazione errore
• Attore primario: Utente autenticato;
• Descrizione: Vengono visualizzati gli errori della configurazione della creazione
del sito se i campi sono vuoti oppure di formattazione errata;
• Pre-condizione: L’utente autenticato ha confermato la creazione del sito e sono
presenti degli errori nei campi dati inseriti;
• Post-condizione: Vengono visualizzati a video gli errori;
• Scenario principale:
1. Vengono visualizzati a video gli errori della configurazione della creazione
del sito.
4.2.11 UC2 - Visita sito
• Attore primario: Utente autenticato;
• Attore secondario: WordPress;
• Descrizione: L’utente autenticato potrà visitare il sito da lui creato;
• Pre-condizione: L’attore vuole visitare il sito creato;
• Post-condizione: L’attore viene rediretto al sito;
• Scenario principale:
1. L’attore verrà reindirizzato al suo sito precedentemente creato.4.3. REQUISITI 21
4.2.12 UC3 - Visualizzazione informazioni
• Attore primario: Utente autenticato;
• Descrizione: L’utente autenticato potrà visualizzare le informazioni del sito,
tra cui il nome del dominio, l’username e la mail dell’account su WordPress e il
tema scelto;
• Pre-condizione: L’utente vuole visualizzare le informazioni del sito;
• Post-condizione: Vengono correttamente visualizzate le informazioni del sito;
• Scenario principale:
1. L’attore può visualizzare le informazioni generali del suo sito.
4.2.13 UC4 - Rimozione sito
• Attore primario: Utente autenticato;
• Attore secondario: WordPress;
• Descrizione: L’utente autenticato potrà cancellare il sito da lui creato;
• Pre-condizione: L’utente vuole cancellare il sito;
• Post-condizione: Il sito è stato cancellato correttamente;
• Scenario principale:
1. L’attore può rimuovere il sito da lui creato.
4.3 Requisiti
In questa sezione vengono elencati e descritti tutti i requisiti rilevati durante la fase di
analisi dei requisiti.
Il codice che identifica un requisito è così strutturato
R[Importanza][Tipologia][Codice]
dove:
• Importanza: ogni requisito ha una sua importanza strategica che può essere di
tre livelli:
– Obbligatorio (0): requisito non più negoziabile o irrinunciabile per il tutor
aziendale;
– Desiderabile (1): rappresenta un valore aggiunto d’interesse riconosciuto
da parte del tutor aziendale;
– Facoltativo (2): requisito relativamente utile per gli scopi dell’add-on.
• Tipologia: ogni requisito si differenzia in tre diverse tipologie:
– Funzionali (F): descrivono funzionalità del sistema;
– Qualitativi (Q): descrivono la qualità del prodotto finale;22 CAPITOLO 4. ANALISI DEI REQUISITI
– Dichiarativi o di vincolo (V): descrivono i vincoli imposti dal tutor
aziendale o dal dominio del problema.
• Codice: ogni requisito ha un codice identificativo univoco.
Nelle seguenti sezioni sono presenti le tabelle che raccolgono tali requisiti. Tali tabelle
sono così formate:
• Codice identificativo: codice che identifica univocamente il requisito, utile per
la tracciabilità;
• Descrizione: breve descrizione testuale del requisito;
• Fonte: fonte da cui è stato dedotto il requisito, utile a fini di tracciabilità.
4.3.1 Requisiti funzionali
ID requisito Descrizione Fonte
L’add-on permetterà all’utente autenticato di po-
R0F0 ter creare un sito, visualizzarlo, visualizzare le sue UC0
informazioni e poterlo rimuovere
L’add-on permetterà all’utente autenticato di poter
R0F1 UC1
creare un sito web in WordPress
L’add-on permetterà all’utente autenticato di poter
R0F1.1 UC1.1
scegliere se utilizzare un proprio dominio personale
L’add-on permetterà all’utente autenticato di poter
R0F1.2 inserire il nome del dominio o del sottodominio del UC1.2
sito
L’add-on permetterà all’utente autenticato di poter
R0F1.3 UC1.3
scegliere il tema del sito tra quelli presenti
L’add-on permetterà all’utente autenticato di poter
R0F1.4 UC1.4
inserire l’email per l’account WordPress
L’add-on permetterà all’utente autenticato di poter
R0F1.5 UC1.5
inserire l’username per l’account WordPress
L’add-on permetterà all’utente autenticato di poter
R0F1.6 UC1.6
inserire la password per l’account WordPress
L’add-on permetterà all’utente autenticato di poter
R0F1.7 UC1.7
confermare la creazione del sito
L’add-on segnalerà all’utente autenticato un errore
R1F1.8 UC1.8
in caso di errata creazione del sito
L’add-on permetterà all’utente autenticato di
R0F2 UC2
visualizzare il sito da lui creato
Continua nella pagina successiva4.3. REQUISITI 23
Continua dalla pagina precedente
ID requisito Descrizione Fonte
L’add-on permetterà all’utente autenticato di vi-
R0F3 sualizzare le informazioni generali relative al sito UC3
creato
L’add-on permetterà all’utente autenticato di
R1F4 UC4
rimuovere il sito creato
Tabella 4.1: Requisiti funzionali
4.3.2 Requisiti qualitativi
ID requisito Descrizione Fonte
Il codice sorgente deve essere commentato secondo lo
R0Q0 Tutor
standard del portale
R0Q1 Devono essere sviluppati ed eseguiti i test di unità Tutor
Tabella 4.2: Requisiti qualitativi
4.3.3 Requisiti di vincolo
ID requisito Descrizione Fonte
L’add-on deve essere sviluppato in Ruby versione Capitolato,
R0V0
2.0.0-p598 Tutor
L’add-on deve essere sviluppato utilizzando il Capitolato,
R0V1
framework Ruby on Rails versione 4.1.8 Tutor
R0V2 I temi del sito devono essere creati in HTML5 e CSS3 Capitolato
I siti saranno in hosting sulla piattaforma multisite
R0V3 Capitolato
di WordPress
WordPress Multisite deve essere eseguita in una
R0V4 Capitolato
macchina virtuale di AWS EC2
R1V5 Il front end dell’add-on deve essere sviluppato in Haml Tutor
Tabella 4.3: Requisiti di vincolo24 CAPITOLO 4. ANALISI DEI REQUISITI
4.3.4 Riepilogo dei requisiti
Tipologia Obbligatorio Desiderabile Facoltativo Totale
Funzionale 11 2 0 13
Qualitativo 2 0 0 2
Di vincolo 5 1 0 6
Totale 18 3 0 21
Tabella 4.4: Riepilogo dei requisitiCapitolo 5
Progettazione e codifica
In questo capitolo vengono descritte le scelte architetturali adottate per lo sviluppo dell’add-
on per MyTemplArt.
5.1 Architettura generale
Viene di seguito fornita una figura illustrativa dell’architettura generale del sistema.
Figura 5.1: Architettura generale
L’intera architettura di MyTemplArt è raccolta all’interno di un container Docker,
che fornisce un’astrazione aggiuntiva grazie alla virtualizzazione a livello di sistema
operativo. MyTemplArt è formata da tanti microservizi che offrono varie funzionalità,
tra cui è presente quella sviluppata nel corso dello stage.
L’utente autenticato inserisce i dati per la creazione del sito e conferma la creazione.
Se non sono presenti errori in fase di configurazione, i dati vengono salvati nel database
del sistema gestito dal DBMS MySQL. Inoltre vengono invitati i dati all’immagine di
WordPress Multisite in hosting su un’istanza di AWS EC2 tramite una HTTP POST
che creerà il sito con il template selezionato e l’utente amministratore del sito. L’altro
amministratore sarà il Network Admin che avrà il controllo su tutti i siti presenti
nella rete dei siti dell’immagine. Infine, una volta creato, il sito interrogherà le API
pubbliche di MyTemplArt tramite una richiesta HTTP GET per ricavare i dati in
formato JSON che andranno ad arricchirlo.
2526 CAPITOLO 5. PROGETTAZIONE E CODIFICA
5.2 Architettura add-on
Per lo sviluppo dell’add-on è stato utilizzato il linguaggio Ruby e il framework Ruby
on Rails. Tale framework usa il design pattern Model-View-Controller (MVC), che
divide il sistema in tre componenti.
Figura 5.2: Design pattern Model-View-Controller generale
Un model in Ruby on Rails è una classe che esegue il mapping di una tabella nel
database ad un file Ruby. La convenzione che Rails incoraggia ad usare è di nominare
il controller al plurale, mentre il nome della classe del model al singolare.
Una view nella configurazione predefinita di Rails è un file in formato erb (embedded
Ruby) che viene convertito in HTML in fase di esecuzione. In alternativa, è possibile
utilizzare altri sistemi di template, come per esempio Haml.
Un controller è una componente lato server di Rails che risponde alle richieste
esterne dal server web all’applicazione, determinando quale file della view visualizzare.
Il controller potrebbe anche dover interrogare uno o più model per informazioni e
passarli alla view. Un controller può fornire una o più actions. In Ruby on Rails, una
action è in genere un’unità che descrive come rispondere a una specifica richiesta del
browser web esterno. Inoltre, il controller /action sarà accessibile per le richieste web
esterne solo se viene mappata una route (percorso) corrispondente. Rails incoraggia gli
sviluppatori a utilizzare RESTful routes, che includono azioni come create, new, edit,
update, destroy, show e index. Queste mappature delle route in arrivo sulle actions del
controller possono essere facilmente impostate nel file di configurazione ’routes.rb’.
5.2.1 Model
PublicWebsite: è la classe del model che gestisce la tabella PublicWebsites. In questa
classe sono presenti le convalidazioni dei dati tramite la keyword ’validates’ che
offre Rails. Le validations vengono utilizzate per garantire che nel database
vengano salvati solo dati validi. In particolare:5.3. DATABASE 27
• user_email: deve essere un indirizzo email valido, con nome identificativo,
seguito dal simbolo @ e dal dominio;
• password: deve avere almeno 8 caratteri.
Tutti i campi dati devono essere presenti e non vuoti.
5.2.2 View
Per la view è stato utilizzato Haml come sistema di template per essere in linea con le
views delle altre funzionalità di MyTemplArt.
I file creati e utilizzati sono:
• index.haml: è la pagina principale dell’add-on. È presente un pulsante per
la creazione del sito. Se è già stato creato il sito, verrà visualizzato un pan-
nello di controllo dove è possibile eliminare il sito, visitarlo oppure visualizzare
le informazioni. Se si sceglie quest’ultima, si viene reindirizzati alla pagina
show.haml;
• show.haml: è la pagina dove sono visualizzate le informazioni del sito, tra cui
il nome del dominio, il tema selezionato e l’username e l’email dell’account.
5.2.3 Controller
PublicWebsitesController: è la classe che si occupa della creazione dei siti grazie
alle action create, new, destroy, show e index. Una volta ricevute dalla view le
informazioni di creazione del sito, le invia al model che le salva nel database e
chiama le API pubbliche di WordPress Multisite per creare il sito web con tali
informazioni.
5.3 Database
Quando viene creato il model, Rails crea automaticamente un file di migrazione del
database. Le migrazioni sono classi di Ruby progettate per semplificare la creazione e la
modifica di tabelle del database. Rails utilizza i comandi rake per eseguire le migrazioni
ed è possibile annullare una migrazione dopo che è stata applicata al database. I nomi
dei file di migrazione includono la data e l’orario di generazione per garantire che
vengano elaborati nell’ordine in cui sono stati creati.
Di base, quando si crea una nuova tabella con Rails viene automaticamente generata la
chiave primaria chiamata semplicemente ’id’ di tipo intero. Inoltre vengono creati altri
due campi chiamati ’created_at’ e ’updated_at’, che impostano la data di creazione e
di ultima modifica rispettivamente.
Le nuove tabelle create per il progetto di stage sono:
PublicWebsites: è la tabella in cui vengono salvati i dati della creazione del sito;28 CAPITOLO 5. PROGETTAZIONE E CODIFICA
Figura 5.3: Nuove tabelle con relazioni
PublicWebsiteTemplates: è la tabella in cui sono salvati i templates con nome e
una breve descrizione del tema.
La tabella Accounts era già presente nel sistema perché creata dal team di sviluppo
di MyTemplArt e i suoi campi dati non sono stati riportati nell’immagine 5.3 per
riservatezza.
Ogni account può avere al massimo un solo sito, ma potrebbe non averne affatto. Un
sito deve avere un solo template, mentre un template può appartenere a più siti.
5.4 Template WordPress
Sono stati sviluppati due templates in WordPress, in accordo con il tutor aziendale. Il
primo, denominato MuseumTheme, è pensato per i proprietari di musei che vogliono
esporre le opere d’arte presenti nella loro galleria, mentre il secondo, ArtistTheme, si
rivolge agli utenti collezionisti o agli artisti.
Il front end è stato realizzato in HTML5 e CSS3, usando Bootstrap 4 come framework,
mentre per il back end le chiamate alle API di MyTemplArt sono state eseguite in
PHP.
5.5 Prodotto finale5.5. PRODOTTO FINALE 29
Figura 5.4: Pagina iniziale dell’add-on
Figura 5.5: Form per la creazione del sito30 CAPITOLO 5. PROGETTAZIONE E CODIFICA
Figura 5.6: Pagina di informazioni del sito
Figura 5.7: Pagina iniziale con gestione sito5.5. PRODOTTO FINALE 31
Figura 5.8: MuseumTheme - Homepage
Figura 5.9: MuseumTheme - Pagina dell’artista singolo32 CAPITOLO 5. PROGETTAZIONE E CODIFICA
Figura 5.10: MuseumTheme - Pagina delle opere d’arte
Figura 5.11: MuseumTheme - Pagina dell’opera d’arte singola5.5. PRODOTTO FINALE 33
Figura 5.12: MuseumTheme - Pagina delle collezioni
Figura 5.13: MuseumTheme - Pagina delle opere d’arte di una collezione
Figura 5.14: MuseumTheme - Pagina di 40434 CAPITOLO 5. PROGETTAZIONE E CODIFICA
Figura 5.15: ArtistTheme - Homepage
Figura 5.16: ArtistTheme - Pagina degli artisti5.5. PRODOTTO FINALE 35
Figura 5.17: ArtistTheme - Pagina dell’artista singolo
Figura 5.18: ArtistTheme - Pagina delle opere d’arte36 CAPITOLO 5. PROGETTAZIONE E CODIFICA
Figura 5.19: ArtistTheme - Pagina dell’opera d’arte singola
Figura 5.20: ArtistTheme - Pagina delle collezioni5.5. PRODOTTO FINALE 37
Figura 5.21: ArtistTheme - Pagina delle opere d’arte di una collezione
Figura 5.22: ArtistTheme - Pagina di 404Capitolo 6
Verifica e validazione
In questo capitolo vengono descritte le tecniche di verifica e validazione utilizzate durante
il progetto.
6.1 Verifica
La verifica è il processo che si occupa di accertare che non siano presenti errori nel
prodotto. Risponde alla domanda "ho sviluppato il sistema correttamente?" e deve
essere eseguita durante tutto lo sviluppo al fine di garantire consistenza, correttezza e
completezza del prodotto software.
6.1.1 Analisi statica
L’analisi statica è una forma di verifica che non richiede l’esecuzione del prodotto e si
accerta che il codice scritto sia qualitativamente corretto.
È stata svolta un’analisi statica del codice da parte dell’IDE Visual Studio Code, che
offre strumenti per avere un feedback diretto sul codice sorgente scritto. Questo ha
garantito la scrittura di codice corretto e di alta qualità.
6.1.2 Analisi dinamica
L’analisi dinamica è una forma di verifica sul prodotto in esecuzione e si basa sul
concetto di test. Un test è una prova delle funzionalità di un sistema con lo scopo di
trovare dei difetti a livello di sviluppo.
Sono stati sviluppati i test di unità che si occupano di provare le singole unità e i
relativi moduli. Di seguito sono riportati i test eseguiti e il loro esito.
ID Descrizione Esito
Verifica che i dati inseriti in fase di creazione del sito
testSaveDb Superato
vengano salvati correttamente nel database
Verifica che avvenga la creazione del sito e dell’utente
testCreateSite Superato
in WordPress
Continua nella pagina successiva
3940 CAPITOLO 6. VERIFICA E VALIDAZIONE
Continua dalla pagina precedente
ID Descrizione Grado
Verifica che avvenga un corretto indirizzamento verso
testVisitSite Superato
il sito
Controlla che siano visualizzate le giuste informazioni
testInfo Superato
del sito
Verifica che avvenga la rimozione del sito in
testRemoveSite Superato
WordPress
Verifica che le chiamate alle API di MyTemplArt
testGetAPI Superato
ritornino i dati corretti
Tabella 6.1: Test di unità
6.2 Validazione
La validazione è il processo che ha come obiettivo l’accertamento che il prodotto sia
conforme alle attese, in modo da soddisfare tutti i requisiti prefissati. Risponde alla
domanda "ho sviluppato il giusto sistema?" e, a differenza della verifica, viene eseguita
al termine del progetto.
Negli ultimi giorni è stata effettuata una validazione interna in modo autonomo al fine
di verificare tutte le funzionalità implementate. In seguito, è stato effettuato anche il
collaudo con la presenza del tutor aziendale, conclusosi con esito positivo.Capitolo 7
Conclusioni
Questo capitolo finale raccoglie il bilancio complessivo dell’esperienza di stage presso
l’azienda Athesys S.r.l.. Vengono valutati gli obiettivi stabiliti inizialmente nel piano di
lavoro e i requisiti soddisfatti. Viene infine tratta una valutazione personale sullo stage.
7.1 Raggiungimento degli obiettivi
7.1.1 Obiettivi aziendali
Codice Descrizione Stato
O-01 Realizzazione di un nuovo add-on per MyTemplArt Completato
Realizzazione di un componente che genera dinami-
O-02 Completato
camente siti pubblici in WordPress
Gestione di un numero di siti tramite WordPress
O-03 Completato
Multisite
Realizzazione di un componente che interroga le API
O-04 Completato
di MyTemplArt
O-05 Realizzazione di templates WordPress Completato
Tabella 7.1: Raggiungimento degli obiettivi
7.1.2 Obiettivi personali
Sono riuscito a soddisfare tutti gli obiettivi personali che mi ero prefissato. Mi sono
integrato all’interno dell’azienda, sia con i dipendenti che con il portale MyTemplArt.
Entrare in confidenza con la struttura del codice ha richiesto un po’ di tempo ma sono
riuscito ad ambientarmi piuttosto velocemente.
Sono stato in grado di sviluppare una componente con il linguaggio Ruby e il framework
Ruby on Rails senza troppi problemi e rimanendo nelle tempistiche prestabilite. Ho
infine approfondito le mie conoscenze di PHP, HTML e CSS.
4142 CAPITOLO 7. CONCLUSIONI
7.2 Resoconto dei rischi
Nella tabella 7.2 sono riportati i rischi precedentemente analizzati nella sezione 2.4. Per
ogni rischio viene indicato se esso è stato riscontrato e il piano adottato per mitigarlo.
Rischio Descrizione Verificato Piano adottato
Il tempo richiesto per l’ap-
Difficoltà tec- prendimento delle nuove Il rischio non si è
No
nologiche tecnologie potrebbe causa- verificato
re ritardi nello sviluppo
I servizi di terze parti po-
trebbero non offrire il ser-
Difficoltà di Il rischio non si è
vizio richiesto oppure le No
realizzazione verificato
funzionalità sono troppo
complesse
Lo sviluppo del progetto
Difficoltà di stage potrebbe non fini- Il rischio non si è
No
tempistiche re nel periodo pianificato a verificato
causa di ritardi
È stato avvisato per
Durante il periodo di sta-
tempo il tutor azienda-
ge è possibile che avvenga-
Impegni per- le e grazie alla pianifi-
no assenze dovute a pro- Sì
sonali cazione iniziale questo
blemi di salute o impegni
rischio non ha creato
personali
problemi
Tabella 7.2: Resoconto dei rischi
7.3 Grado di soddisfacimento dei requisiti
Al termine dello stage sono stati soddisfatti tutti i requisiti analizzati nella sezione 4.3.
Di seguito viene riportata la tabella di riepilogo dei requisiti soddisfatti.
Tipologia Numero requisiti Soddisfatti
Funzionale 13 13
Qualitativo 2 2
Di vincolo 6 6
Totale 21 21
Tabella 7.3: Requisiti soddisfattiPuoi anche leggere
