Università degli Studi di Padova - SIAGAS

Pagina creata da Domenico Costantini
 
CONTINUA A LEGGERE
Università degli Studi di Padova - SIAGAS
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
Università degli Studi di Padova - SIAGAS
Davide Tognon: Generazione dinamica di siti pubblici in WordPress tramite AWS EC2
e Ruby on Rails, Tesi di laurea triennale, c Dicembre 2019.
Università degli Studi di Padova - SIAGAS
È questione di un attimo e ci si perde davvero.
        — Gazebo Penguins - Nebbia

       Dedicato a mia madre Roberta.
Università degli Studi di Padova - SIAGAS
Università degli Studi di Padova - SIAGAS
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
Università degli Studi di Padova - SIAGAS
Università degli Studi di Padova - SIAGAS
“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
Università degli Studi di Padova - SIAGAS
Università degli Studi di Padova - SIAGAS
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
Università degli Studi di Padova - SIAGAS
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                                                                                                                                    51
Elenco 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

                                                  xi
5.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

                                                        xii
Capitolo 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.

                                             1
2                                                   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

                                              5
6                                              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 successiva
8                                         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 stage
Capitolo 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.

                                             9
10                                  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 Docker
3.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:

                                               15
16                                          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 successiva
4.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 vincolo
24                                   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 requisiti
Capitolo 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.

                                              25
26                                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 finale
5.5. PRODOTTO FINALE                                        29

                Figura 5.4: Pagina iniziale dell’add-on

               Figura 5.5: Form per la creazione del sito
30               CAPITOLO 5. PROGETTAZIONE E CODIFICA

     Figura 5.6: Pagina di informazioni del sito

     Figura 5.7: Pagina iniziale con gestione sito
5.5. PRODOTTO FINALE                                               31

                  Figura 5.8: MuseumTheme - Homepage

           Figura 5.9: MuseumTheme - Pagina dell’artista singolo
32                       CAPITOLO 5. PROGETTAZIONE E CODIFICA

        Figura 5.10: MuseumTheme - Pagina delle opere d’arte

     Figura 5.11: MuseumTheme - Pagina dell’opera d’arte singola
5.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 404
34                CAPITOLO 5. PROGETTAZIONE E CODIFICA

         Figura 5.15: ArtistTheme - Homepage

     Figura 5.16: ArtistTheme - Pagina degli artisti
5.5. PRODOTTO FINALE                                                35

           Figura 5.17: ArtistTheme - Pagina dell’artista singolo

            Figura 5.18: ArtistTheme - Pagina delle opere d’arte
36                      CAPITOLO 5. PROGETTAZIONE E CODIFICA

     Figura 5.19: ArtistTheme - Pagina dell’opera d’arte singola

         Figura 5.20: ArtistTheme - Pagina delle collezioni
5.5. PRODOTTO FINALE                                                           37

      Figura 5.21: ArtistTheme - Pagina delle opere d’arte di una collezione

                   Figura 5.22: ArtistTheme - Pagina di 404
Capitolo 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

                                             39
40                                     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.

                                            41
42                                                      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 soddisfatti
Puoi anche leggere