Motore di ricerca ed estrazione dati avanzato su un

Università di Padova

Dipartimento di Matematica

"Tullio Levi-Civita"

Corso di Laurea in Informatica

Motore di ricerca ed estrazione dati avanzato suun modello relazionale

Laureando:Dan Serbanoiu 1072680

Relatore:Professor Gilberto Filè

Tutor Aziendale:Ing. Massimo Grava

Anno Accademico 2016/2017

Dan Serbanoiu: Motore di ricerca ed estrazione dati avanzato su unmodello relazionale,Tesi di laurea triennale, @ Settembre 2017.

Dedico questo lavoro allafamiglia passata, presente e futura e agli

amici passati, presenti e futuri.

Ringraziamenti

Innanzitutto, vorrei esprimere la mia gratitudine al Prof. Gilberto Filè, relatoredella mia tesi, per il feedback fornitomi nella revisione della tesi.

Ringrazio l’azienda FuturaSI srl, in particolar modo il mio tutor aziendale, l’In-gegner Massimo Grava, per il supporto fornitomi durante il periodo di stage eanche per avermi aiutato nella rilettura della tesi.

Ringrazio i miei genitori, che mi sono sempre stati vicino in questi anni e mihanno fornito un aiuto prezioso, senza il quale non avrei potuto realizzare le mieaspirazioni. Grazie anche te, nonna, per tutto il cibo che mi hai cucinato conamore.

Ringrazio l’ESU per avermi ospitato.

Ringrazio l’Università degli Studi di Padova, che è stata dura ma giusta.

Ringrazio Claudio Guidi, collaborando con il quale ho potuto apprendere un ap-proccio ingegneristico alla progettazione del software che mi ha aiutato moltonei miei progetti successivi.

Ringrazio tutti gli amici e le amiche conosciuti durante il periodo di studio al-l’Università.

Voglio fare un ringraziamento particolare a Tania Sanna e Kety Mayelin Jime-nez Tejeda, per avermi sempre sostenuto e per aver creduto in me.

Padova, Settembre 2017 Dan Serbanoiu

Sommario

Lo scopo del seguente documento è quello di illustrare il lavoro svolto du-rante lo stage curriculare presso l’azienda Futurasi S.r.l con sede a Oderzo traluglio e settembre 2017. L’obiettivo dello stage era la realizzazione full-stackdi un motore di ricerca su un modello relazionale con capacità di estrazionedati avanzate e interfaccia web totalmente dinamica, da integrare nella nuovapiattaforma web che l’azienda sta costruendo. I linguaggi di programmazioneusati per l’implementazione del software prodotto sono TypeScript e Aureliaper il front-end e C# per il back-end.

Indice

1 Introduzione 11.1 L’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Unico3, il prodotto di punta di FuturaSI srl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2.1 Unico3 Gestionale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.2 Unico3 Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.3 Unico3 Geolocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.4 Unico3 Planner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.5 Unico3 Magbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3.1 Obiettivi dello stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3.2 Obiettivi personali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3.3 Piani�cazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Tecnologie e strumenti 62.1 Tecnologie di sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 JavaScript ES6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2 TypeScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.3 Aurelia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.4 C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Strumenti di Con�gurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.1 Aurelia CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.2 NPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Strumenti a supporto dei processi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.1 Visual Studio 2017 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.2 Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.3 Stash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Realizzazione del progetto 133.1 Analisi Dei Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1 Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.1.2 Interfaccia Utente Sviluppata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.1.3 Casi d’Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2 Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2.1 Architettura Front-End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2.2 Architettura Back-End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.2.3 Design Pattern Utilizzati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2.4 Veri�ca e Validazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5

INDICE INDICE

4 Valutazione Retrospettiva 424.1 Soddisfacimento dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2 Divario conoscitivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.3 Considerazioni personali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

A Glossario 44

6

Elenco delle �gure

1.1 Logo di FuturaSI srl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Gantt Piano di Progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 Logo di Typescript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Logo di Aurelia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Architettura MVVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Logo di C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5 Logo di NPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.6 Logo di Visual Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.7 Logo di Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.8 Logo di Stash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1 Schermata Interfaccia Utente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 UC0 - Scenario Principale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3 UC1 - Costruzione Dinamica di una Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.4 UC1.2.1 - Costruzione Criterio Semplice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.5 UC1.2.2 - Costruzione Criterio Collezione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.6 UC1.2.3 - Costruzione Criterio su Riferimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.7 UC1.2.4 - Generazione Lista di Criteri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.8 UC3 - Salvataggio Query Costruita . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.9 UC4 - Caricamento Query Precedentemente costruita . . . . . . . . . . . . . . . . . . . . . . . . . 243.10 UC5 - Cancellazione Query Precedentemente costruita . . . . . . . . . . . . . . . . . . . . . . . . 243.11 UC7 - Generazione Risultato di Ricerca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.12 Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.13 Search.Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.14 Search.Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.15 Search.Query.Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.16 Search.Selectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.17 Search.Persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.18 Search.Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.19 Search.Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.20 Unico3.Search.Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.21 Unico3.Search.Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.22 Query::getQueryExpression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.23 Unico3.Search.ServiceStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.24 Singleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.25 Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

7

ELENCO DELLE FIGURE ELENCO DELLE FIGURE

3.26 Speci�cation Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.27 Strategy Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.28 Unico3.Search.Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

8

Capitolo 1Introduzione

Il seguente capitolo ha la funzione di fornire informazioni sull’azienda presso la quale è stato svolto lo stage e fornireuna descrizione degli obiettivi da raggiungere e la piani�cazione delle attività.

1.1 L’azienda

Figura 1.1: Logo di FuturaSI srl

Futura Soluzioni Informatiche srl è una azienda fondata nel 1995 attualmente operante a Oderzo nel settore deiSoftware ERP, sistemi di gestione o sistemi informativi, che integrano tutti i processi di business rilevanti.

1.2 Unico3, il prodotto di punta di FuturaSI srl

L’azienda sviluppa un programma chiamato Unico3, un gestionale verticale sviluppato per le aziende operan-ti nel settore della manutenzione e installazione di impianti termici. Il programma era inizialmente locale eveniva installato sulle macchine dei clienti, mentre ora è cloud e fornisce il servizio in modalità Software-as-a-Service.

1

Unico3, il prodotto di punta di FuturaSI srl 1. Introduzione

1.2.1 Unico3 Gestionale

Il programma fornisce ad ogni azienda detentrice di una licenza la possibilità di gestire l’installazione di mol-teplici tipologie di impianti a loro a�dati (ad es. di riscaldamento, condizionamento, di depurazione), la loromanutenzione, la modulistica per gli adempimenti richiesti dalla legge, lo storico, la contabilità, la piani�cazionedei processi di lavoro. Al programma è a�ancato un solido reparto di assistenza.

Gestione Amministriva

Il programma fornisce funzioni che, normalmente, sono di competenza del personale amministrativo, ad esempiola gestione delle fatture emesse e ricevute, incassi e guadagni, gestione della modulistica da erogare in base allepiù recenti leggi governative, ad esempio le ricevute �scali e i rapporti di controllo relativi agli impianti.

Gestione Installazione

ll programma incorpora per ogni azienda un database degli impianti oggetto di installazione o manutenzionee fornisce funzioni atte alla gestione del processo di installazione o manutenzione, ad esempio le gestione deipreventivi, le commesse dei lavori di installazione, l’analisi dei costi e dei fabbisogni.

Gestione magazzino

Per ogni azienda vi è la gestione del magazzino relativa ai pezzi di ricambio indispensabili per le operazionidi installazione e manutenzione e tutte le procedure che, normalmente, vengono utilizzate per la gestione deimagazzini.

Gestione Agenda

Per ogni azienda vi è la piani�cazione ed ottimizzazione dell’attività dei vari tecnici, permettendo di ridurre alminimo gli spostamenti ed i tempi morti tra interventi successivi.

Assistenza Remota

Per qualsiasi problematica di utilizzo o malfunzionamenti del programma vi è un reparto di assistenza sempreattivo tutti i giorni dal lunedì al venerdì. L’assistenza si rende necessaria, essendo il programma molto complessoe anche i clienti molto numerosi.

2

Unico3, il prodotto di punta di FuturaSI srl 1. Introduzione

1.2.2 Unico3 Mobile

È la versione di Unico3 per smartphone, sviluppata per essere utilizzata dai tecnici nel settore HVAC. Fornisceai tecnici un’agenda personale nella quale vengono riportati tutti gli appuntamenti del giorno con le indica-zioni principali e permette una immediata identi�cazione tecnica dell’impianto e dell’intervento che si andràad e�ettuare. Svolge anche la funzione di navigatore, in quanto con un semplice tocco sulla posizione del-l’impianto è attivabile Google Maps che porterà il tecnico direttamente a destinazione senza dover reinserirel’indirizzo.

1.2.3 Unico3 Geolocation

Il programma permette di visualizzare su una mappa geogra�ca una visione completa della situazione dei tec-nici sul territorio integrata con le informazioni provenienti dal sistema gestionale. È così possibile un e�cacemonitoraggio dello stato di avanzamento del lavoro sui singoli interventi programmati permettendo così unamigliore piani�cazione che consente signi�cativi risparmi su tempi e distanze di percorrenza e si traduce in con-sistenti risparmi di carburante, usura dei mezzi e tempo del personale a disposizione per l’intervento. Un reportgiornaliero permette di analizzare, per singolo tecnico, tutta l’attività svolta in modo cronologico mettendola aconfronto con l’attività piani�cata. Vengono riepilogati, tra l’altro, i km totali percorsi nella giornata, il numerodi interventi e�ettuati, il tempo impiegato negli interventi ed il tempo di percorrenza.

1.2.4 Unico3 Planner

Dato che per ogni tipo di impianto ci sono delle operazioni da svolgere periodicamente è stato recentementeintegrato un algoritmo di ricerca operativa che in base alla dispozione geogra�ca dei clienti di una data aziendasuggerisce alle aziende la data, il percorso e il tecnico più adatto a svolgere l’intervento. Questa funzione ottimiz-za la piani�cazione dell’intera giornata redistribuendo gli impegni tra tutti i tecnici in modo da minimizzare ilpercorso complessivo. In caso di assenza di un tecnico o di rottura di un furgone, permette di ripiani�care in tem-po reale tutta l’agenda, minimizzando il numero di appuntamenti tralasciati assegnando priorità agli interventipiù urgenti.

1.2.5 Unico3 Magbar

Il programma integra un terminale di magazzino progettato per avere la massima a�dabilità. Ha integrato unlettore Barcode, possibilità di e�ettuare ricerche in tempo reale su tutto l’archivio, gestione delle giacenze eposizione articoli e accesso istantaneo a tutte le informazioni necessarie.

3

Stage 1. Introduzione

1.3 Stage

1.3.1 Obiettivi dello stage

L’azienda sta costruendo una nuova piattaforma web che andrà a sostituire l’attuale Unico3 Gestionale, la qualedarà la possibilità ad utenti autorizzati di e�ettuare ricerche molto complesse sull’universo dei dati dell’applica-tivo Unico3 e permetterà di esportare i risultati ottenuti in CSV/Excel e PDF. Al momento le ricerche sono createmanualmente entità per entità. Si vuole quindi automatizzare questo processo aumentando molto la semplicitàd’uso e la �essibilità, e allo stesso tempo riducendo drasticamente i tempi di sviluppo. Lo stage ha quindi comeobiettivo la realizzazione di un motore di ricerca con estrazione dati avanzato su un modello relazionale e di unacorrispondente interfaccia web totalmente dinamica che permetta di poter costruire query ed e�ettuare ricerchemolto complesse sull’universo dei dati dell’applicativo Unico3.

Per portare a termine il progetto è stata fatta la seguente piani�cazione analitica delle attività da svolgere durantelo stage:

1. Imparare TypeScript e imparare a utilizzare il Framework Aurelia e C# (inclusi concetti avanzati di C# comeRe�ection ed Expressions);

2. Progettare e programmare un modulo che generi i metadati per tutto l’Universo dei dati di Unico3 a partireda un assembly contenente una lista di tutte le de�nizioni di ogni tipo di dato;

3. Progettare e programmare un form dinamico e ricorsivo tramite il quale sia possibile costruire criteri esottocriteri di una query profonda n livelli e ampia k nodi con n e k in�niti. Il form deve essere programmatousando TypeScript e il framework Aurelia, che implementa il pattern MVVM e deve generare una strutturaJSON che modella un Albero k-ario. Le scelte possibili ad ogni livello sono determinate tramite analisi deimetadati generati. Deve essere possibile salvare e caricare le query.

4. Progettare e programmare in C# un modulo di ricerca che a partire dalla struttura dati ad Albero ricevutain input dal client, costruisca ricorsivamente un’Expression che rappresenta la query voluta. I modelli deidati di Unico3 sono già stati mappati al database usando il framework LLBLGen Pro, che implementa ilpattern ORM. Una volta costruita l’Expression, è da passare come input al connettore che si interfacciacon i dati mappati, la Expression viene eseguita sui dati (l’esecuzione dell’Expression sui dati è equivalenteall’esecuzione della query direttamente sull’istanza del database) e il risultato ottenuto ritornato al client;

5. Integrare o programmare un plugin che permetta, dopo aver ricevuto il risultato della ricerca, di visualiz-zarlo in una griglia e prevedere la possibilità di esportare tale griglia in formato PDF e CSV/Excel;

6. E�ettuare test di integrazione e validazione sul prodotto;

7. Scrivere una documentazione minimale che spieghi come con�gurare l’applicativo e come usarlo;

4

Stage 1. Introduzione

1.3.2 Obiettivi personali

La scelta del progetto di tirocinio proposta da FuturaSI è stata dettata dai seguenti motivi:

1. Avere la possibilità di lavorare con e imparare da professionisti esperti nella progettazione e sviluppo disoftware anche molto complessi usati nel mondo reale da numerosi utenti;

2. Imparare ad utilizzare con pro�tto nuovi strumenti di sviluppo, in particolare JavaScript e il framework Au-relia, per poter arricchire il mio curriculum nell’ambito dello sviluppo web e apprendere strumenti e�caciche serviranno per lo sviluppo di un progetto molto complesso indipendente;

3. Mettermi alla prova per dimostrare che, dopo anni di studio all’Università degli Studi di Padova, sonoin grado di auto-gestire e portare a termine un progetto complesso, dove non ho familiarità con lo stacktecnologico da utilizzare;

1.3.3 Piani�cazione

In seguito a un’analisi approfondita della piani�cazione analitica è stata fatta la seguente suddivisione temporaledelle attività. Le scadenze di seguito decise sono state rispettate senza deviazioni importanti durante tutto ilperiodo dello stage:

Periodo Attività Ore

24/07/2017 - 28/07/2017 Formazione sull’utilizzo del framework Aurelia e TypeScript 40

31/07/2017 - 04/08/2017 Formazione sull’utilizzo di ASP.NET Core + ServiceStack 40

07/08/2017 - 11/08/2017 Progettazione Architettura in dettaglio del Prodotto Software da svi-luppare e Scrittura modulo per la generazione dei Metadati latoserver

40

14/08/2017 - 18/08/2017 Scrittura form ricorsivo per la generazione delle query lato client 40

21/08/2017 - 25/08/2017 Scrittura modulo di ricerca lato server 40

28/08/2017 - 01/09/2017 Scrittura delle funzionalità rimanenti lato client, scelta e integrazione deiplugin utilizzati

40

04/09/2017 - 08/09/2017 Integrazione dei moduli sviluppati, Veri�ca e Validazione 40

11/09/2017 - 13/09/2017 Stesura della documentazione minimale su con�gurazione e utilizzo inMarkdown

24

Figura 1.2: Gantt Piano di Progetto

5

Capitolo 2Tecnologie e strumenti

Il seguente capitolo ha la funzione di descrivere lo stack tecnologico e l’ambiente di sviluppo utilizzato nell’ambitodello stage.

2.1 Tecnologie di sviluppo

2.1.1 JavaScript ES6

ECMAScript (o ES) è un linguaggio di programmazione standardizzato e mantenuto da Ecma International. Unadelle sue implementazioni più conosciute è JavaScript, la cui ultima versione è stata pubblicata nel 2015 ed è notacome ECMAScript 2015 o ES6. ES6 aggiunge a JavaScript una lista di funzionalità, alcune delle quali sono:

• Supporto per le costanti: il concetto di costante in ES6 si riferisce a una variabile il cui valore è immutabile;

• Possibilità di istanziare variabili e funzioni disponibili solo nello scope di de�nizione;

• L’introduzione delle funzioni a freccia, che hanno sintassi più compatta e non de�niscono più il propriothis, come le normali funzioni JavaScript, ma lo ereditano dallo scope padre, come ci si aspetta in uno stiledi programmazione orientato agli oggetti;

• Possibilità di speci�care valori di default per i parametri delle funzioni;

• Supporto per importazione/esportazione da/a moduli, funzionalità che risolve il problema del con�itto dellevariabili a livello di namespace globale;

• Possibilità di de�nire classi, come in un linguaggio orientato agli oggetti.

• Più semplice de�nire ereditarietà, nelle versioni precedenti era possibile solo tramite l’uso dei prototype,adesso usando la keyword extends. Più intuitivo anche l’accesso ai membri delle classi base;

• Aggiunta costrutti come map o set, che facilitano la manipolazione degli Array;

• Possibilità di tipizzare gli Array;

• Introduzione delle Promise, che sono oggetti che rappresentano valori che saranno resi disponibili in futuro,perchè devono ancora essere calcolati o presi da una fonte dati. Sono de�nite convenzioni per accedere aidati di una Promise una volta disponibile e anche per speci�care il �usso di esecuzione solo dopo che i datisono disponibili;

6

Tecnologie di sviluppo 2. Tecnologie e strumenti

Data la recente pubblicazione di ES6, non tutte le nuove funzionalità sono supportate dai JavaScript engine piùdi�usi pertanto è stato usato un transpiler o transcompiler, che traduce codice scritto in ES6 in un programmaequivalente scritto in un ES5. Per l’implementazione dell’interfaccia utente di questo applicativo è stato usato iltranspiler di TypeScript.

2.1.2 TypeScript

Figura 2.1: Logo di Typescript

De�nito da Microsoft, si tratta di un linguaggio che estende ES6 aggiungendo il supporto della tipizzazione statica.Un’applicazione TypeScript viene compilata in JavaScript secondo le speci�che ES5. Dal momento che ES6 è unsottoinsieme di TypeScript, è possibile usare il suo transpiler per compilare codice ES6 in ES5.

Aggiunge a JavaScript:

• Possibilità di speci�care staticamente tipi per le variabili;

• Possibilità di speci�care staticamente il tipo di ritorno delle funzioni o dei metodi;

• Speci�catori di accesso sugli oggetti o loro campi dati: public, protected, private;

• Meccanismo di templating delle classi tramite Generics;

• Possibilità di scrivere interfacce che possono diventare il contratto di un oggetto di istanza;

Avere un sistema tipizzato rende il codice più mantenibile, meno soggetto a errori e permette all’IDE utilizzatoun’analisi statica più avanzata e autocompletamento del codice.

7


2.1.3 Aurelia

Figura 2.2: Logo di Aurelia

Aurelia è un framework JavaScript lato client che implementa il pattern MVVM, supporta ES6 e TypeScript efavorisce la convenzione sopra la con�gurazione.

Le sue funzionalità più importanti e sfruttate durante lo sviluppo dell’interfaccia utente del prodotto sono:

Architettura MVVM

Figura 2.3: Architettura MVVM

L’architettura MVVM separa la presentazione (interfaccia utente) di un’applicazione e la logica che guida lapresentazione. È un’architettura a strati e modulare derivata dal pattern Model-View-Controller (MVC). Comeconseguenza del disaccoppiamento dei componenti, in un’architettura MVVM si hanno buone manutenibilità,testabilità e estensibilità. Similmente ai controller del pattern MVC, le View-Model espongono i dati alle viewassociate e incapsulano la logica di interazione (chiamate ai servizi, navigazione, trasformazioni di stato).

In Aurelia l’architettura MVVM viene realizzata tramite:

• Elementi Compose: è possibile inserire una View e un View-Model in una View contenitrice;

• Routing e Navigazione: usando il sistema di navigazione di Aurelia è possibile richiedere una View inun contenitore e sostituirla al posto di un’altra o altre e automaticamente associarle il suo View-Model;

• Elementi Custom: è possibile in Aurelia de�nire un elemento che corrisponde a una View oppure a unacoppia View e View-Model e iniettarlo dentro una View, esporre proprietà su cui è possibile fare il bindingdelle variabili appartenenti a un contesto diverso e gestire eventi di ciclo di vita. Ogni elemento custom hail suo container;

8


Data Binding

La logica di push/pull è sostituita con una logica piú dichiarativa che permette di associare dinamicamente aelementi dell’interfaccia utente oggetti e proprietà di oggetti (anche in entrambe le direzioni). La sintassi perde�nire questa associazione è minimale e l’implementazione tiene conto della performance.

Meccanismo per la Dependency Injection

La dependency Injection è un design pattern il cui scopo è passare agli oggetti i riferimenti delle istanze di altrioggetti da cui essi dipendono, evitando che ognuno costruisca esplicitamente i tipi che gli servono, cosa che ren-derebbe di�cile la condivisione delle stesse istanze tra oggetti diversi. Collegato a questo è un pattern chiamatoInversione di Controllo (IoC) che descrive uno scenario in cui gli oggetti danno la responsabilità della propriacostruzione e delle proprie parti a un’entità esterna.

In Aurelia vi è un meccanismo automatico che permette facilmente di gestire le dipendenze esterne che una clas-se ha. Una volta resi accessibili al codice consumatore i moduli esterni attraverso il meccanismo degli import,è su�ciente dichiarare sulla classe consumatrice tutti i moduli da cui la classe dipende tramite inject decorator,mediante la seguente sintassi:

@inject(type[,type2,...])

export class ClassName {

...

}

import e inject decorator sono funzionalità ES6 supportate sia da Babel che da TypeScript.

Quando poi il costruttore di una classe è chiamato, il Dependency Injection Container di Aurelia crea le istanzedei tipi speci�cati come dipendenze e passa il riferimento di quelle istanze al costruttore.

In Aurelia sono supportati i seguenti cicli di vita per le variabili iniettate tramite decoratore:

• Singleton: oggetto istanziato solo la prima volta che viene chiamato e riferimento a quest’unica istanzapassato a ogni oggetto che lo richiede;

• Transient: per ogni nuova richiesta viene creata una nuova istanza dell’oggetto;

Routing

ll router in Aurelia permette di comporre ricorsivamente le Views e di speci�care la navigazione dall’una all’altra.All’origine vi è sempre una sola coppia View e View-Model. In ogni View-Model (a qualsiasi livello della gerarchiadell’applicazione) è possibile con�gurare il router attraverso l’implementazione di con�gureRouter() per de�nirequale composizione di View e View-Model corrisponde a ogni route o path.

9


2.1.4 C#

Figura 2.4: Logo di C#

Il C# è un linguaggio di programmazione orientato agli oggetti sviluppato da Microsoft all’interno dell’inizia-tiva .NET, e successivamente approvato come standard dalla Ecma e ISO. Le funzionalità di C# che sono statemaggiormente usate durante il corso del progetto sono:

Re�ection

Fornisce oggetti (di tipo Type) che descrivono assembly, moduli e tipi. È possibile utilizzare la re�ection per crearein modo dinamico un’istanza di un tipo, associare il tipo a un oggetto esistente o ottenere il tipo da un oggettoesistente, nonché richiamarne i metodi o accedere ai campi e alle proprietà dell’oggetto. La re�ection consenteinoltre di accedere agli eventuali attributi utilizzati nel codice. La re�ection è stata utilizzata nello sviluppo delmodulo lato server che aveva la funzione di estrarre i metadati dall’assembly contenente l’universo dei dati diUnico3 e anche per tipizzare le Expressions generate.

Expressions

Un Expression in C# è una sequenza di uno o più operandi e zero o più operatori che può essere valutata a unsolo valore, oggetto, metodo o namespace.

ServiceStack

È un framework delle versioni di .NET superiori a .NET 3.5, che esegue su ASP.NET. Facilita l’implementazionedi API REST-ful.

10

Strumenti di Con�gurazione 2. Tecnologie e strumenti

2.2 Strumenti di Con�gurazione

2.2.1 Aurelia CLI

È uno strumento da riga di comando che permette di creare un boilerplate minimale di un’applicazione Aureliae di con�gurarla in base alle necessità. La con�gurazione �nale per l’applicazione web client è:

• Gestore del caricamento dei moduli e �le Javascript: RequireJS;

• Transpiler: TypeScript;

• Esecutore test di unità: Karma;

2.2.2 NPM

Figura 2.5: Logo di NPM

NPM è un gestore di pacchetti per i moduli di Node.js e permette agli sviluppatori JavaScript di condividere eriusare codice e di aggiornare facilmente il codice condiviso.

È stato usato per scaricare e gestire le versioni dei plugin usate per alcune componenti dell’interfaccia gra�cadell’applicativo lato client.

11

Strumenti a supporto dei processi 2. Tecnologie e strumenti

2.3 Strumenti a supporto dei processi

2.3.1 Visual Studio 2017

Figura 2.6: Logo di Visual Studio

Un ambiente di sviluppo integrato sviluppato da Microsoft, che supporta attualmente diversi tipi di linguaggio,quali C, C++, C#, F#, Visual Basic .Net, Html e JavaScript, e che permette la realizzazione di applicazioni, sitiweb, applicazioni web e servizi web. È stato usato nella fase di codi�ca dell’interfaccia utente e della parteserver.

2.3.2 Git

Figura 2.7: Logo di Git

È un sistema di controllo distribuito, creato da Linus Torvalds nel 2005, direttamente utilizzabile da riga di coman-do e serve per tracciare le modi�che ai �le e coordinare il lavoro di più persone su questi �le. È usato di normaper gestire il codice sorgente nello sviluppo software. Garantisce velocità, integrità dei dati e supporta processi dilavoro distribuiti e non lineari. È stato usato per gestire e salvare su un server git le versioni del codice sorgentedell’applicativo sviluppato durante il progetto. I commit sono avvenuti sempre sul branch master.

2.3.3 Stash

Figura 2.8: Logo di Stash

Per conservare le versioni dell’applicativo ottenute durante il ciclo di sviluppo è stato usato Stash di Atlassian,un’implementazione enterprise di server git, integrata con un sistema di project management e gestione dellesegnalazioni.

12

Capitolo 3Realizzazione del progetto

Il seguente capitolo ha la funzione di presentare il lavoro fatto.

3.1 Analisi Dei Requisiti

3.1.1 Requisiti

Per individuare i requisiti associati sono stati usati come riferimento il Piano di Lavoro e le riunioni avvenutedurante lo stage col tutor aziendale.

Per l’identi�cazione dei requisiti è stata utilizzata la seguente codi�ca:

• il codice di ogni requisito avrà come prima lettera la lettera R maiuscola;

• La seconda lettera indica il tipo di requisito:

– F per funzionale;

– P per prestazionale;

– V per vincolo;

• La terza lettera indica la precedenza:

– O per obbligatorio;

– F per facoltativo;

• L’ultima parte del codice identi�cativo del requisito consiste in un numero decimale con la classi�cazionedecima Dewey;

In seguito alle discussioni fatte con il tutor aziendale, prima e durante lo svolgimento dello stage, sono statidelineati i seguenti requisiti del software da realizzare.

13

Analisi Dei Requisiti 3. Realizzazione del progetto

Requisiti Funzionali

Codice Descrizione

RFO1 L’utente può costruire una Query con criteri di ricerca complessi ricorsivi emultilivello

RFO1.1 I criteri di ricerca possono essere speci�cati sull’oggetto della ricerca

RFO1.2 I criteri di ricerca possono essere speci�cati su oggetti collegati 1-1 o 1-* (con criteri"Tutti"/"Almeno uno"/"Nessuno")

RFO1.3 I criteri di ricerca possono essere combinati in gruppi AND/OR multipli

RFO1.4 Deve essere possibile scegliere le proprietà del risultato della ricerca

RFO3 Deve essere possibile e�ettuare una ricerca utilizzando la Query costruita

RFO4 Deve essere possibile visualizzare i risultati della ricerca in una griglia dinamica

RFO5 Deve essere possibile esportare i risultati in PDF e CSV/Excel

RFO6 Deve essere possibile salvare e caricare le Query generate

Requisiti di Qualità

Codice Descrizione

RQO1 Devono essere scritti test di Veri�ca e Validazione che il prodotto �nale deve superare

RQO2 Il prodotto �nale deve essere depositato su una repository git

RQO3 Deve essere stilata una documentazione minimale che spieghi come con�gurarel’applicazione e come utilizzarla

Requisiti di Vincolo

Codice Descrizione

RVO1 Il Front-end deve essere sviluppato utilizzando HTML5, TypeScript e il frameworkAurelia

RVO2 Il Back-end deve essere sviluppato su piattaforma ASP.NET Core + ServiceStack nellinguaggio C#

RVO3 Le Query costruite lato Front-End devono essere salvate su Localstorage

RVO4 I dati passati tra il server e il client devono essere in formato JSON

RVO5 Gli attributi che è possibile scegliere a ogni livello nell’editor di query devono esserecoerenti con la struttura dei dati di Unico3

14


3.1.2 Interfaccia Utente Sviluppata

Figura 3.1: Schermata Interfaccia Utente

Viene presentata l’interfaccia utente �nale sviluppata nella quale, per ogni elemento dell’interfaccia a cui corri-sponde una funzionalità, sono stati annotati i codici dei casi d’uso, i quali sono descritti nella sezione seguente.Lo scopo è esempli�care come un utente dell’applicazione può avvalersi della funzionalità descritta per ogni casod’uso.

L’interfaccia utente mostrata non è nella sua versione di produzione, ma è stata sviluppata separando completamentela struttura degli elementi del DOM e lo stile gra�co dalla logica che guida l’interazione, consentendo poi a un terzodi cambiare il layout senza doversi necessariamente preoccupare di come è implementata la logica sottostante. Èpossibile mantenere la suddetta logica senza modi�che per l’integrazione con la versione mobile di Unico3, poichè usaApache Cordova.

15


3.1.3 Casi d’Uso

Vengono di seguito forniti i casi d’uso che modellano i requisiti funzionali, ovvero le funzioni o servizi o�erti dalsistema, così come sono percepiti e utilizzati dagli attori che interagiscono col sistema stesso. I casi d’uso usanouna codi�ca nella forma:

UC[codice univoco del padre].[codice progressivo del figlio]

UC0 - Scenario Principale

Figura 3.2: UC0 - Scenario Principale

UC0 - Scenario Principale

Attori Utente autorizzato

Descrizione L’attore si trova nella schermata principale dell’applicazione ed accede allefunzionalità a lui disponibili: può costruire dinamicamente una query, può ef-fettuare il reset della query, può salvare la query costruita, caricarne una pre-cedentemente salvata, cancellarne una precedentemente salvata, può eseguireuna query e successivamente vedere il risultato della query eseguita.

Pre-Condizioni L’utente ha avuto accesso al modulo di ricerca dell’applicazione

16


Post-Condizioni L’applicazione ha eseguito le richieste dell’attore

Scenario Principale (1.) L’attore può costruire una query dinamicamente (UC1);(2.) L’attore può e�ettuare il reset della query, ovvero può cancellare la querycostruita riportandone lo stato al nodo iniziale (UC2);(3.) L’attore può salvare la query costruita in memoria, per permetterne ilcaricamento in una fase successiva (UC3);(4.) L’attore può caricare dalla memoria una query precedentemente salvata(UC4);(5.) L’attore può cancellare dalla memoria una query precedentemente salvata(UC5);(6.) L’attore può eseguire la query (UC6) e in seguito interagire con il risultatoottenuto (UC7);

Scenari Alternativi (1.) L’attore può visualizzare un errore dovuto al fatto che non è stato sceltonessun criterio per la ricerca (UC8.1);(2.) L’attore può visualizzare un errore dovuto al fatto che non è stata sceltanessuna proprietà per il risultato di ritorno (UC8.2);(3.) L’attore può visualizzare un errore dovuto al fatto che non è stato possibileraggiungere il server per e�ettuare la ricerca (UC8.3);

17


UC1 - Costruzione Dinamica di una Query

Figura 3.3: UC1 - Costruzione Dinamica di una Query

UC1 - Costruzione Dinamica di una Query


Descrizione L’attore si trova nella schermata principale dell’applicazione e sta costruendouna query tramite le funzionalità a lui disponibili: può scegliere un elementopadre o usare l’elemento di default ed a partire dall’elemento scelto può ge-nerare un albero di criteri di diverso tipo e può selezionare le proprietà chesaranno visibili nel risultato di ritorno

Pre-Condizioni L’utente ha avuto accesso al modulo di ricerca dell’applicazione

Post-Condizioni L’applicazione ha costruito dinamicamente una query

Scenario Principale (1.) L’attore può scegliere un elemento Padre (UC1.1), altrimenti il sistema nesceglie uno di default (UC1.1.1) e in seguito può costruire un albero di criterida applicare all’elemento padre di tipo criterio semplice (UC1.2.1) o criteriocollezione (UC1.2.2) o criterio su riferimento (UC1.2.3) o una lista di criteri(UC1.2.4);(2.) L’attore può selezionare una lista di proprietà che corrispondono alle co-lonne del risultato di ritorno (UC1.3), ma non è vincolato a farlo poiché ci sonodelle proprietà di default pre-selezionate (UC1.3.1);

18


UC1.2.1 - Costruzione Criterio Semplice

Figura 3.4: UC1.2.1 - Costruzione Criterio Semplice

UC1.2.1 - Costruzione Criterio Semplice


Descrizione L’attore ha scelto di costruire un criterio semplice: può scegliere una proprietàtra quelle disponibili, può scegliere un operatore di paragone e può scegliereun valore su cui e�ettuare il paragone in relazione alla proprietà

Pre-Condizioni L’utente ha iniziato la costruzione della query e il criterio semplice corrente è�glio diretto dell’elemento padre scelto al punto di partenza della costruzionedella query o di un criterio a sua volta �glio di suddetto elemento

Post-Condizioni L’applicazione ha costruito il criterio in base agli input dell’utente

Scenario Principale (1.) L’attore può scegliere una proprietà semplice da una lista di proprietà ap-partenenti all’oggetto padre del criterio corrente (UC1.2.1.1);(2.) L’attore può scegliere un operatore di paragone da applicare alla proprietàscelta: di uguaglianza, di disuguaglianza, maggiore, maggiore o uguale, mino-re o minore o uguale (UC1.2.1.2);(3.) L’attore può scegliere un valore dello stesso tipo della proprietà sceltain UC1.2.1.1, da paragonare alla proprietà con l’operatore scelto in UC1.2.1.2(UC1.2.1.3);(4.) L’attore può incapsulare il criterio costruito in una Lista di criteri(UC1.2.1.4);

19


UC1.2.2 - Costruzione Criterio Collezione

Figura 3.5: UC1.2.2 - Costruzione Criterio Collezione

UC1.2.2 - Costruzione Criterio Collezione


Descrizione L’attore ha scelto di costruire un criterio collezione: può scegliere una pro-prietà di tipo Collezione tra quelle disponibili, può scegliere un operatore diparagone e può scegliere un albero di criteri su cui e�ettuare il paragone inrelazione alla proprietà scelta

Pre-Condizioni L’utente ha iniziato la costruzione della query e il criterio collezione corrente è�glio diretto dell’elemento padre scelto al punto di partenza della costruzionedella query o di un criterio a sua volta �glio di suddetto elemento

Post-Condizioni L’applicazione ha costruito il criterio in base agli input dell’utente

Scenario Principale (1.) L’attore può scegliere una proprietà collezione da una lista di proprietàappartenenti all’oggetto padre del criterio corrente (UC1.2.2.1);(2.) L’attore può scegliere un operatore da applicare alla collezione scelta: Tut-ti, Almeno Uno o Nessuno (UC1.2.2.2);(3.) L’attore può generare un albero di criteri su cui valutare la collezione scel-ta in base all’operatore scelto (UC1.2.2.3);(4.) L’attore può incapsulare il criterio costruito in una Lista di criteri(UC1.2.1.4);

20


UC1.2.3 - Costruzione Criterio su Riferimento

Figura 3.6: UC1.2.3 - Costruzione Criterio su Riferimento

UC1.2.3 - Costruzione Criterio su Riferimento


Descrizione L’attore ha scelto di costruire un criterio su un riferimento: può scegliereun riferimento tra quelli disponibili, può generare un albero di criteri sulriferimento scelto, può incapsulare il criterio costruito in una Lista di criteri

Pre-Condizioni L’utente ha iniziato la costruzione della query e il criterio riferimento cor-rente è �glio diretto dell’elemento padre scelto al punto di partenza dellacostruzione della query o di un criterio a sua volta �glio di suddetto elemento

Post-Condizioni L’applicazione ha costruito il criterio riferimento in base agli input dell’utente

Scenario Principale (1.) L’attore può scegliere una proprietà riferimento da una lista di proprietàappartenenti all’oggetto padre del criterio corrente (UC1.2.3.1);(2.) L’attore può generare un albero di criteri sul riferimento scelto (UC1.2.3.2);(3.) L’attore può incapsulare il criterio costruito in una Lista di criteri(UC1.2.3.3);

21


UC1.2.4 - Generazione Lista di Criteri

Figura 3.7: UC1.2.4 - Generazione Lista di Criteri

UC1.2.4 - Generazione Lista di Criteri


Descrizione L’attore ha scelto di costruire una lista di criteri: può scegliere un operatorelogico (AND oppure OR) con cui concatenare tutti gli elementi della lista, puòaggiungere o rimuovere criteri dalla lista

Pre-Condizioni L’utente ha iniziato la costruzione della query e la lista di criteri corrente è�glia diretta dell’elemento padre scelto al punto di partenza della costruzionedella query o di un criterio a sua volta �glio di suddetto elemento

Post-Condizioni L’applicazione ha costruito una lista di criteri in base agli input dell’utente

Scenario Principale (1.) L’attore può scegliere un’operatore logico (AND (UC1.2.4.1.1) oppure OR(UC1.2.4.1.2)) con cui concatenare i criteri della lista (UC1.2.4.1);(2.) L’attore può aggiungere un criterio o albero di criteri alla lista (UC1.2.4.2);(3.) L’attore può rimuovere un criterio o albero di criteri dalla lista (UC1.2.4.3);

22


UC3 - Salvataggio Query Costruita

Figura 3.8: UC3 - Salvataggio Query Costruita

UC3 - Salvataggio Query Costruita


Descrizione L’attore si trova nella schermata principale dell’applicazione e sta salvando laquery costruita: può scegliere un nome univoco per la query e confermare ilsalvataggio

Pre-Condizioni L’attore ha costruito una query o modi�cato una query esistente

Post-Condizioni L’applicazione ha salvato la query costruita

Scenario Principale (1.) L’attore può scegliere un nome univoco per la query (UC3.1);(2.) L’attore può confermare il salvataggio (UC3.2);

Scenari Alternativi (1.) il salvataggio della query è fallito poichè esiste già una query salvata conil nome scelto. È possibile sovrascrivere (UC3.3);

23


UC4 - Caricamento Query Precedentemente costruita

Figura 3.9: UC4 - Caricamento Query Precedentemente costruita

UC4 - Caricamento Query Precedentemente costruita


Descrizione L’attore sta caricando una query sulla base del nome

Pre-Condizioni Esistono query precedentemente salvate

Post-Condizioni L’applicazione ha e�ettuato il caricamento della query scelta

Scenario Principale (1.) L’attore può scegliere una query usandone il nome (UC4.1);(2.) L’attore può confermare il caricamento (UC4.2);

UC5 - Cancellazione Query Precedentemente costruita

Figura 3.10: UC5 - Cancellazione Query Precedentemente costruita

UC5 - Cancellazione Query Precedentemente costruita


Descrizione L’attore sta cancellando una query sulla base del nome

Pre-Condizioni Esistono query precedentemente salvate

Post-Condizioni L’applicazione ha e�ettuato la cancellazione della query scelta

Scenario Principale (1.) L’attore può scegliere una query usandone il nome (UC5.1);(2.) L’attore può confermare la cancellazione (UC5.2);

24


UC7 - Generazione Risultato di Ricerca

Figura 3.11: UC7 - Generazione Risultato di Ricerca

UC7 - Generazione Risultato di Ricerca


Descrizione L’attore si trova nella schermata principale dell’applicazione, ha costruito unaquery ed ha e�ettuato la ricerca e può interagire col risultato ritornato dallaricerca

Pre-Condizioni È stata eseguita una ricerca su una query

Post-Condizioni L’applicazione ha eseguito le richieste dell’attore sul risultato

Scenario Principale (1.) L’attore può visualizzare i risultati della query in griglia (UC7.1) o nessunrisultato (UC7.1.1);(2.) L’attore può scegliere il layout per la stampa del pdf (UC7.2), se non sceglieha un valore di default (UC7.2.1);(3.) L’attore può esportare la griglia con i risultati in PDF (UC7.3);(4.) L’attore può esportare la griglia con i risultati in CSV/Excel (UC7.4);

25

Progettazione 3. Realizzazione del progetto

3.2 Progettazione

Questa sezione descrive i risultati della progettazione e�ettuata durante lo stage, che ha preceduto ed accompa-gnato la codi�ca. I diagrammi delle classi qui di seguito descritti rispecchiano nella struttura e nelle associazionila versione più recente del codice prodotto.

3.2.1 Architettura Front-End

Search

Figura 3.12: Search

Il seguente package mostra una visione ad alto livello dell’architettura front-end dell’applicativo sviluppato. Sear-chRoot condivide con tutti i moduli �gli di questo alcuni dati come il modello dati della Query, i risultati dellaricerca e alcune variabili per il controllo dello stato e per la gestione degli errori.

Le classi che �niscono per .CustomElement sono una coppia View e View-Model ove il binding dei dati tra la View eil View-Model viene gestito dal Framework Aurelia.

26


Search.Plugins

Figura 3.13: Search.Plugins

Questo package contiene elementi custom Aurelia o classi che mediante l’uso del pattern Adapter si interfaccianocon plugin esterni per realizzare alcune delle funzionalità dell’interfaccia utente dell’applicativo.

1. ag-grid-search utilizza il plugin aurelia-ag-grid per implementare una griglia dinamica;

2. pdf-make-search utilizza la libreria open source pdf-make per implementare la funzione della stampa supdf di una tabella. Riceve in input un array di oggetti il cui tipo viene determinato a tempo di runtime;

3. selectize-search utilizza la libreria open source di JQuery UI selectize per implementare una select chepermette di selezionare opzioni multiple e anche di ordinare le opzioni selezionate tramite drag and drop;

4. semanticui-con�rm-modal utilizza una funzionalità del framework SemanticUI per realizzare una �nestradi conferma;

5. semanticui-actiondropdown utilizza una funzionalità del framework SemanticUI per realizzare menu drop-down dove ogni opzione rappresenta un’azione o un gruppo di azioni;

6. semanticui-input-modal utilizza una funzionalità del framework SemanticUI per realizzare una �nestra chepermette di immettere un input e confermare oppure cancellare;

7. semanticui-message utilizza una funzionalità del framework SemanticUI per realizzare un messaggio dierrore o avvertimento;

27


Search.Query

Figura 3.14: Search.Query

Questo modulo contiene una gerarchia di elementi custom Aurelia che tramite la loro composizione, realizzatatramite il meccanismo di composizione degli elementi custom di Aurelia, implementano un editor o form ricorsivoe multilivello. Nello stato iniziale della costruzione di una Query è richiesto che venga scelto un elemento padreutilizzando il selettore Search.Selectors.Operands.SelectOperand e il tipo di questo valore diventa il tipo padre ditutto l’albero di criteri. È necessario scegliere, anche successivamente ma prima di e�ettuare la ricerca, tramite ilselettore Search.Selectors.Result.SelectResultPropertiesCustomElement una lista di proprietà sul tipo padre sceltoper il risultato di ritorno e l’ordine in cui si vuole che compaiano. Una volta scelto l’elemento padre è possibileiniziare la costruzione dei criteri per la ricerca a partire da questo elemento. A ogni livello e per ogni nodo èpossibile avere una lista di criteri e questa funzionalità è fornita dal CompositeCriteriaCustomElement, altrimentia ogni livello e per ogni nodo è possibile scegliere attraverso il selettore Search.Selectors.Operands.SelectOperanduna proprietà il cui tipo diventerà padre di tutta la gerarchia di criteri inferiore. Sulla base del tipo della proprietàscelta saranno disponibili elementi di input di�erenti che permetteranno di costruire criteri di tipo:

1. CollectionCriteriaCustomElement: la costruzione di un criterio su una Collezione;

2. ReferenceCriteriaCustomElement: la costruzione di un criterio su un Riferimento;

3. SimpleCriteriaStringCustomElement, SimpleCriteriaTimeCustomElement, SimpleCriteriaNumberCustomE-lement, SimpleCriteriaBooleanCustomElement: la costruzione di un criterio su una proprietà di tipo sem-plice (primitivi e tipi che rappresentano una data del calendario);

A ogni tipo di criterio corrispondono elementi di input che permettono di scegliere l’operatore tramite un selettoredi tipo Search.Selectors.Operators.SelectOperator e il valore (solo per i criteri semplici) tramite un selettore oelemento di input a seconda dei casi di tipo Search.Selectors.Values.SelectValue.

Ogni nodo può essere in qualsiasi momento trasformato in un CompositeCriteria, ovvero in una lista di criteri, ilcui tipo padre resta quello del nodo che è stato composto. Un criterio convertito in un CompositeCriteria ne diven-

28


ta il nodo di estrema sinistra. Ad un CompositeCriteria è possibile aggiungere criteri o rimuovere quelli presentie nel caso di rimozione si rimuove il nodo corrispondente al criterio e tutto il sottoalbero. Un CompositeCriteriapermette di scegliere un operatore logico tramite Search.Selectors.Operators.SelectOperator.

Ad ogni criterio corrisponde un modello che salva lo stato del criterio costruito (input inseriti, operandi scelti,valori, gerarchia di sotto criteri se presente).

Di seguito il modulo contenente i modelli per ogni tipo di criterio.

Figura 3.15: Search.Query.Models

Qualora si dovesse modi�care un nodo diverso da una foglia dell’albero cambiandone la proprietà con una didiverso tipo i suoi sottocriteri vengono eliminati, in quanto non più rilevanti nei confronti del diverso tipo padrescelto.

29


Usando l’editor per costruire una Query per la ricerca che modelli:

"Trova tutti gli Impianti dove il Comune sia Oderzo e le Caldaie abbiano almeno una DataTermineContratto maggioredi 27/02/2017 e IsAttivato della proprietà Conto sia false"

l’editor costruirebbe una struttura JSON uguale alla seguente:

1 {

2 "entity": "Impianti",

3 "criteria": [

4 {

5 "type" : "composite-criteria",

6 "operator": "AND",

7 "criteria": [

8 {

9 "type": "simple-criteria-string",

10 "name": "Comune",

11 "operator": "Equal",

12 "value": "Oderzo"

13 },

14 {

15 "type": "collection-criteria",

16 "name": "Caldaie",

17 "operator": "ANY",

18 "criteria": {

19 "type": "simple-criteria-time",

20 "name": "DataTermineContratto",

21 "operator": "GREATERTHAN",

22 "value": "27/02/2017"

23 }

24 },

25 {

26 "type": "reference-criteria".

27 "name": "Conto",

28 "criteria": {

29 "type": "simple-criteria-boolean",

30 "name": "IsAttivato",

31 "operator": "EQUAL",

32 "value": "false"

33 }

34 }

35 ]

36 }

37 }

30


Search.Selectors

Figura 3.16: Search.Selectors

Questo modulo contiene una gerarchia di elementi custom Aurelia usati da Search.Query per inserire gli inputper ogni criterio costruito.

1. Il modulo Search.Selectors.Operands contiene elementi custom che realizzano selettori usati per selezionarele proprietà;

2. Il modulo Search.Selectors.Operators contiene elementi custom che realizzano selettori per selezionareoperatori;

3. Il modulo Search.Selectors.Values contiene elementi custom che realizzano selettori oppure elementi diinput per scegliere o inserire valori. Questi elementi cambiano implementazione oppure modalità di inse-rimento a seconda del tipo di valore da inserire;

4. Il modulo Search.Selectors.Result contiene un selettore multiplo per le proprietà del risultato di ritorno;

Tutti i selettori calcolano le opzioni di scelta che rendono disponibili a ogni livello dell’albero dei criteri diuna query sulla base dei metadati ricevuti dal back-end che vengono calcolati e resi disponibili dal moduloSearch.Services.Metadata.

31


Search.Persistence

Figura 3.17: Search.Persistence

Questo modulo contiene un elemento custom Aurelia che permette di fare il reset, salvare, caricare o cancellareuna Query e per fare questo si appoggia su Search.Services.Save. I plugin dipendenti speci�cati servono per lagestione errori oppure per inserire input (nome della query).

Search.Result

Figura 3.18: Search.Result

Questo modulo contiene un elemento custom Aurelia che, in seguito a una ricerca e�ettuata tramite Search.Services.Search,rende disponibile sullo schermo una griglia con i dati del risultato di ritorno usando Search.Plugins.ag-grid-searche permette di stampare su pdf usando Search.Plugins.pdf-make-search.

32


Search.Services

Figura 3.19: Search.Services

Questo modulo contiene i servizi mediante i quali l’applicazione frontend comunica con il back-end.

1. Il modulo Search.Services.Medata contiene le classi che recuperano i metadati dal back-end. La classe chee�ettua la richiesta al back-end è Metadatadb, mentre MetadataInfo è utilizzata per fornire i dati ai moduliche lo richiedono. Per fare la richiesta viene usata la libreria aurelia-http-fetch-client di Aurelia;

2. La classe Search invia la Query costruita al back-end e resta in ascolto per ricevere il risultato della ricerca.Per fare la richiesta viene usata la libreria aurelia-http-fetch-client di Aurelia;

3. La classe Save interagisce con Localstorage per gestire la persistenza delle Query: salvare, cancellare,caricare;

33


3.2.2 Architettura Back-End

Unico3.Search.Metadata

Figura 3.20: Unico3.Search.Metadata

Questo package contiene delle classi che hanno la responsabilità di estrarre i metadati da un’assembly contenenteil modello dei dati di Unico3, mappato al database di Unico3 tramite ORM. ExecuteParse è una classe Singletonche preso in input il suddetto assembly ne estrae una lista di tutti i tipi e passa questa lista a un’istanza di Parser,il quale costruisce una lista di Entity, che sarà poi convertita in un JSON, contenente i metadati necessari apoter e�ettuare una richiesta di ricerca rilevante. Normalmente sarebbe stato necessario modellare un grafo, mala natura del modello di dati di Unico3 rende possibile l’utilizzo di una struttura piú semplice. Dato che tuttele classi del modello ereditano da una sola classe base comune, è stato su�ciente estrarre una lista di tutte leclassi che ereditano da questa sola classe base e per ciascuna la lista delle proprietà: ogni proprietà può avere tipoprimitivo (String, Integer, Double, Bool) oppure Date, Time, DateTime oppure essere un Riferimento o Collezionederivato dalla classe base comune. Per modellare tutti i metadati necessari e su�cienti a permettere di costruiretutte le query possibili rilevanti alla fonte di dati queryabile basta quindi una lista di Entity. È stata scritta ancheuna classe MetadataInfo per permettere di e�ettuare query sui metadati estratti.

34


Di seguito un estratto del JSON generato a partire dal risultato di Unico3.Search.Metadata.Parser::Parse(types):

1 [

2 {

3 "name": "AliquotaIVAEntity",

4 "properties": [

5 {

6 "name": "Catturato",

7 "type": "String",

8 "nullable": false,

9 "baseType": null

10 },

11 {

12 "name": "IsEsclusoDaListe",

13 "type": "Bool",


15 "baseType": null

16 },

17 ...

18 ]

19 },

20 {

21 "name": "AnagraficaEntity",

22 "properties": [

23 {

24 "name": "Tab074",

25 "type": "Collection",


27 "baseType": "ContrattoEntity"

28 },

29 {

30 "name": "Codice",

31 "type": "Integer",

32 "nullable": true,

33 "baseType": null

34 },

35 {

36 "name": "AnagraficaAzienda",

37 "type": "Reference",


39 "baseType": "CATEntity"

40 },

41 ...

42 ]

43 },

44 ...

45 ]

35


Unico3.Search.Query

Figura 3.21: Unico3.Search.Query

Figura 3.22: Query::getQueryExpression

36


Questo package descrive il modulo dell’applicativo che genera un’Expression che modella la Query e una chemodella le proprietà del risultato di ritorno. La gerarchia di classi qui descritta modella un Albero k-ario con kuguale al numero di criteri presenti per ogni livello della gerarchia, che possono essere variabili. Di fatto ogninodo di tipo ReferenceCriteria, CollectionCriteria e CompositeCriteria può avere come �glio un CompositeCrite-ria, il quale contiene una Lista di ICriteria di qualsiasi tipo. Il pattern che è stato usato è lo Speci�cation Pattern.Questo pattern isola le regole di Business in base al principio SRP (Single Responsibility Principle) e poi ricor-sivamente le compone e concatena attraverso operatori per ottenere il risultato voluto. Ogni regola è chiamataSpeci�ca nel Speci�cation Pattern, mentre in questo caso rappresenta un criterio della logica relazionale. Diseguito è descritto il metodo

Query::getQueryExpression()

che ricorsivamente costruisce l’Expression totale.

Ogni nodo costruisce un’Expression equivalente all’operazione che rappresenta. SimpleCriteriaString, Simple-CriteriaBoolean, SimpleCriteriaNumber e SimpleCriteriaTime sono foglie dell’albero, in quanto non contengonoulteriori sotto-Expression. Tutti gli altri criteri costruiscono se stessi parzialmente e concludono la propria co-struzione una volta ricevuta l’Expression corrispondente al sotto-albero di criteri, calcolata a ogni livello e perogni nodo mediante

ICriteria::GetPredicateExpression(basetype : string, father: Expression)

Ogni nodo, per poter essere calcolato correttamente, riceve dal chiamante, ovvero dal nodo padre, il nome deltipo del padre e l’Expression corrispondente al parametro equivalente alla proprietà del criterio padre. Nel casodi un nodo CompositeCriteria la costruzione avviene concatenando tramite operatore logico tutte le Expressionottenute sui nodi �gli.

Se Unico3.Search.Query.Query modellasse un’istanza equivalente a:

"Trova tutti gli Impianti a cui è associato il cognome Rossi oppure il cognome Verdi e in cui la descrizione del comuneè uguale a Oderzo e in almeno uno dei Contratti isSospensione è falso "

Query::getQueryExpression() genererebbe la seguente Expression:

1 . Lambda #Lambda1<System . Func ‘ 2 [ Unico 3 . Core . Database . E n t i t y C l a s s e s . I m p i a n t o E n t i t y , System . Boolean ] >( Unico 3 . Core . Database . E n t i t y C l a s s e s . I m p i a n t o E n t i t y$ I m p i a n t o E n t i t y )

2 {3 ( $ I m p i a n t o E n t i t y . Cognome == " ROSSI " | | $ I m p i a n t o E n t i t y . Cognome == " VERDI " ) && ( $ I m p i a n t o E n t i t y . Comune ) . D e s c r i z i o n e == "ODERZO"4 && . C a l l System . L inq . Enumerable . Any (5 $ I m p i a n t o E n t i t y . C o n t r a t t i ,6 . Lambda #Lambda2<System . Func ‘ 2 [ Unico 3 . Core . Database . E n t i t y C l a s s e s . C o n t r a t t o E n t i t y , System . Boolean ] >)7 }89 . Lambda #Lambda2<System . Func ‘ 2 [ Unico 3 . Core . Database . E n t i t y C l a s s e s . C o n t r a t t o E n t i t y , System . Boolean ] >( Unico 3 . Core . Da tabase . E n t i t y C l a s s e s . C o n t r a t t o E n t i t y

$ C o n t r a t t o E n t i t y )10 {11 $ C o n t r a t t o E n t i t y . I s S o s p e n s i o n e == F a l s e12 }

In�ne se poi si volessero estrarre dal risultato solo i campi Nominativo, Indirizzo, NumeroCivico a quest’Expres-sion bisognerebbe applicare la seguente Expression, generata daQuery::getSelectorExpression(dynamicType):

1 . Lambda #Lambda1<System . Func ‘ 2 [ Unico 3 . Core . Database . E n t i t y C l a s s e s . I m p i a n t o E n t i t y , DynamicClass 1 ] >( Unico 3 . Core . Database . E n t i t y C l a s s e s . I m p i a n t o E n t i t y $x )2 {3 . New DynamicClass 1 ( ) {4 Nominat ivo = $x . Nominat ivo ,5 I n d i r i z z o = $x . I n d i r i z z o ,6 NumeroCivico = $x . NumeroCivico7 }8 }

37


Unico3.Search.ServiceStack

Figura 3.23: Unico3.Search.ServiceStack

Questo package descrive i servizi dell’applicativo che accettano le richieste tramite HTTP. Rappresenta il puntodi accesso tramite il quale e�ettuare le operazioni del backend dell’applicativo. La classe MetadataService imple-menta un servizio che permette a un client di richiedere i metadati estratti dall’Universo dei dati Unico3. La classeSearchService implementa un servizio che accetta dal client un JSON contenente l’Albero dei criteri generati dalform di ricerca sviluppato e tramite la classe JsonQuery lo trasforma tramite ricorsione in un oggetto Query.L’oggetto Query genera l’Expression relativa alla Query nel modo descritto e l’Expression relativa ai campi volu-ti nel risultato di ritorno e tramite il QueryExecutor applica le suddette Expression sul modello dei dati mappatotramite ORM al database. Il risultato ottenuto dalla Query viene quindi ritornato al client in formato JSON. Laserializzazione del risultato di ritorno è gestita dal framework Servicestack.

38


3.2.3 Design Pattern Utilizzati

Singleton

Figura 3.24: Singleton

Il singleton è un design pattern creazionale che ha lo scopo di garantire che di una determinata classe vengacreata una e una sola istanza, e di fornire un punto di accesso globale a tale istanza. Viene usato quando siha un oggetto necessario per coordinare azioni nel sistema, fornire dati consistenti o immutabili o mantene-re stati condivisi tra più moduli necessari al buon funzionamento del sistema. Le classi che sono singleton sonoSearch.Services.Metadatainfo, Search.Services.Search, Search.Services.Save e Unico3.Search.Metadata.ExecuteParse.

Adapter

Figura 3.25: Adapter

Ogni qual volta nel progetto di un software si debbano utilizzare sistemi di supporto (come per esempio librerie)la cui interfaccia non è perfettamente compatibile nel contesto di sviluppo in cui si vuole utilizzarle, si può creareuna classe che faccia da tramite, chiamata Adapter. Nell’ambito del progetto sviluppato sono stati creati Adapterper tutti i plugins usati nella parte Front-End (in Search.Plugins), che in alcuni casi erano plugin di JQuery chenon funzionavano correttamente calati in un contesto asincrono o dove i dati cambiano o sono disponibili soloin seguito a una richiesta o un calcolo di cui non si conosce la durata.

39


Speci�cation Pattern

Figura 3.26: Speci�cation Pattern

Un pattern che permette di concatenare regole di business tramite la logica booleana. Prendendo ispirazione daquesto pattern è stato progettato il modulo Unico3.Seach.Query e Search.Query.

Strategy Pattern

Figura 3.27: Strategy Pattern

L’obiettivo di questo pattern è poter de�nire diverse implementazioni di un algoritmo e incapsularle in classile quali implementano la stessa interfaccia e sono richiamate a tempo di esecuzione attraverso questa comuneinterfaccia in base ai criteri del contesto di esecuzione. È possibile usare lo strategy pattern anche nel caso in cui sivuole fornire un implementazione temporanea di una funzionalità critica e in seguito sarà più semplice cambiarequesta implementazione senza dover modi�care codice. Lo Strategy pattern è stato usato nella progettazione diUnico3.Search.Metadata.IParser, Unico3.Search.Metadata.IMetadataInfo e Search.Selectors.

40


3.2.4 Veri�ca e Validazione

Figura 3.28: Unico3.Search.Test

Prima della conclusione dello stage è stato possibile fare solamente i test di unità dei moduli del back-end del-l’applicativo e sono stati implementati mediante l’utilizzo di una libreria C# chiamata FluentAssertions.

Non sono stati fatti i test di unità della parte Front-End, ma ne è stato provato il funzionamento direttamente daltutor aziendale.

41

Capitolo 4Valutazione Retrospettiva

In questo ultimo capitolo sono state riportate le valutazioni e le considerazioni in merito al completamento degliobiettivi pre�ssati e alla crescita personale e professionale maturata da questa esperienza.

4.1 Soddisfacimento dei requisiti

Qui di seguito è riportata una tabella contenente i requisiti dichiarati in fase di progettazione e il loro stato diavanzamento percentuale:

Codice AvanzamentoRequisiti Funzionali

RFO1 100%RFO1.1 100%RFO1.2 100%RFO1.3 100%RFO1.4 100%RFO3 100%RFO4 100%RFO5 50%RFO6 100%

Requisiti di QualitàRQO1 50%RQO2 100%RQO3 50%

Requisiti di VincoloRVO1 100%RVO2 100%RVO3 100%RVO4 100%RVO5 100%

Durante lo stage è stato possibile soddisfare quasi tutti i requisiti, eccezione fatta per la scrittura di test relativialla parte front-end dell’applicazione, la scrittura di un manuale utente e l’esportazione in CSV/Excel.

42

Divario conoscitivo 4. Valutazione Retrospettiva

4.2 Divario conoscitivo

Le conoscenze in mio possesso acquisite durante il corso di laurea triennale sono state adeguate e più che su�-cienti allo svolgimento dell’attività di stage.

Le nozioni acquisite durante il corso e il progetto di Ingegneria del Software sono state fondamentali nell’a�ron-tare l’analisi dei requisiti, nella de�nizione delle attività da svolgere per soddisfarli, nella riduzione del temponecessario a portare a termine ogni attività e nella progettazione del prodotto da sviluppare.

Le nozioni acquisite durante il corso di Programmazione e di Algoritmi e Strutture Dati sono state essenzialinell’aiutarmi a de�nire modelli dei dati appropriati e sviluppare moduli fatti di procedure ricorsive complesse elavorare con gli Alberi k-ari.

Le nozioni acquisite durante il corso di Programmazione ad Oggetti e Programmazione Concorrente e Distribuitami hanno facilitato nell’apprendimento di C# e nello sviluppo di codice conforme agli standard attesi da unaprogrammazione ad oggetti e modulare.

4.3 Considerazioni personali

Al termine dell’attività di stage presso FuturaSI srl ho potuto fare il punto della situazione per quanto riguarda ilcontributo fornitomi da questa esperienza alla mia crescita professionale e personale.

Lavorare a questo progetto è stato molto utile, in quanto mi ha permesso di soddisfare alcuni miei obiettivi perso-nali riguardanti l’apprendimento di nuove tecnologie web. È stato anche possibile consolidare alcune conoscenzeche già avevo e in alcuni casi ho potuto correggere alcuni miei modi di procedere che ho scoperto essere errati ocomunque non ottimali.

Ho potuto portare a termine il progetto con pro�tto, collaborando a un prodotto che verrà usato nel mondo realeda numerosi clienti paganti.

Per me è stata dunque un’esperienza fortemente positiva, che mi ha fatto crescere dal punto di vista lavorativo eumano.

43

Appendice AGlossario

A

Assembly

è l’output compilato di codice C#, può essere una dll o un exe. È la più piccola unità di deployment. Contienecodice .NET compilato a MSIL (Microsoft Intermediate language) che sarà compilato in codice nativo (da uncompilatore Just In time) la prima volta che sarà eseguito su una macchina data. Quel codice compilato saràsalvato in assembly e usato per chiamate. Solitamente un assembly è un �le �sico su disco, ma può essere piú�le.

C

Collection

In C# sono strutture dati che danno un modo più �essibile per lavorare con gruppi di oggetti. A di�erenza degliarray, i gruppi di oggetti con cui si lavora possono crescere e diminuire dinamicamente a seconda dei bisognidell’applicazione. È possibile scegliere:

• System.Collections.Generic: List<T>, Dictionary<TKey,TValue>, Queue<T>, SortedList<TKey,TValue>,Stack<T>;

• System.Collections.Concurrent: BlockingCollection<T>, ConcurrentDictionary<TKey,TValue>, Con-currentQueue<T>, and ConcurrentStack<T> per operazioni thread-safe;

• ICollection<T>: è l’interfaccia di base per le classi di System.Collections.Generic dello spazio dei nomi edestende IEnumerable<T>, IDictionary<TKey, TValue> e IList<T>;

44

A. Glossario

D

Delegato C#

Un delegato è un tipo che incapsula in modo sicuro un metodo, in modo simile a un puntatore a funzione in C eC++. Ad esempio si consideri:

public delegate int MyDelegate (string s);

questo riferimento può essere usato per riferire qualsiasi metodo che ha un solo parametro string e ritorna unint come variabile.

Dependency Injection

L’idea alla base della Dependency Injection è quella di avere un componente esterno (assembler) che si occupidella creazione degli oggetti e delle loro relative dipendenze e di assemblarle mediante l’utilizzo dell’injection. Inparticolare esistono tre forme di injection:

• Constructor Injection: dove la dipendenza viene iniettata tramite l’argomento del costruttore;

• Setter Injection: dove la dipendenza viene iniettata attraverso un metodo set;

• Interface Injection: che si basa sul mapping tra interfaccia e relativa implementazione;

E

Espressione lambda C#

È una funzione anonima che è possibile usare per creare delegati o tipi di alberi delle espressioni. È possibilescrivere funzioni locali che possono essere passate come argomenti o restituite come valore (Utile per scritturaquery LINQ).

Estensibilità

Quando in un sistema è possibile aggiungere facilmente nuove funzionalità senza dover modi�care troppo oa�atto il codice esistente. Si ha quando è stata fatta una buona progettazione dell’architettura.

I

Incapsultamento

Nell’ambito dell’informatica, la tecnica di nascondere il funzionamento interno, deciso in fase di progettazione,di una parte di un programma, in modo da proteggere le altre parti del programma dai cambiamenti che siprodurrebbero in esse nel caso che questo funzionamento fosse difettoso, oppure si decidesse di implementarloin modo diverso. Per avere una protezione completa è necessario disporre di una robusta interfaccia che proteggail resto del programma dalla modi�ca delle funzionalità soggette a più frequenti cambiamenti.

45

A. Glossario

Disaccoppiamento

Un tipo di comunicazione tale che un modulo A che invoca il modulo B sia meno dipendente possibile daesso.

M

Mantenibilità

Quando si ha un’architettura con componenti disaccoppiate ed è semplice correggere bug o aggiungere funzio-nalità senza causare bug ad altre componenti durante il processo.

O

ORM

l’Object-Relational Mapping (ORM) è una tecnica di programmazione che favorisce l’integrazione di sistemisoftware aderenti al paradigma della programmazione orientata agli oggetti con sistemi RDBMS.

R

Re�ection

La re�ection speci�ca oggetti di tipo Type, che descrivono assembly, moduli e tipi. È possibile usare la re�ectionper creare in modo dinamico un’istanza di un tipo, associare il tipo a un oggetto esistente oppure ottenere il tipoda un oggetto esistente e richiamarne i metodi o accedere ai relativi campi e proprietà.

T

Testabilità

Quando si ha un architettura con componenti disaccoppiati ed è facile scrivere test di unità sulla logica diinterazione.

Transpiler

Converte del codice sorgente di un linguaggio a codice sorgente in un altro linguaggio.

46

Bibliogra�a

• Sito internet di wikipedia, rielaborazione dei termini per il glossariohttp://en.wikipedia.orghttp://en.wikipedia.org

• Sito internet di FuturaSI srlhttp://www.futurasi.comhttp://www.futurasi.com

• Guide to the Software Engineering Body of Knowledge (SWEBOK)https://www.computer.org/web/swebok/https://www.computer.org/web/swebok/

• Libro sul framework AureliaLearning Aurelia by Manuel Guilbault

• Sito usato come riferimento per ES6http://es6-features.org/http://es6-features.org/

http://en.wikipedia.org

http://www.futurasi.com

https://www.computer.org/web/swebok/

http://es6-features.org/

Documents

Motore di ricerca ed estrazione dati avanzato su un