• Non ci sono risultati.

Capitolo 4: Architettura del software

N/A
N/A
Protected

Academic year: 2021

Condividi "Capitolo 4: Architettura del software"

Copied!
7
0
0

Testo completo

(1)

22

Capitolo 4: Architettura del software

In questo capitolo viene descritta la logica del noto pattern architetturale Model-View-Controller (MVC), poi viene descritta la struttura del framework PHP Laravel analizzando alcune cartelle. La documentazione [6] dice che è una struttura di default pensata per definire un ottimo punto di partenza per applicazioni sia gradi che piccole, ma è possibile organizzarla diversamente. Nel corso del tirocinio si è preferito non modificarla.

4.1 Il pattern Model-View-Controller

L’MVC [8] è utilizzato in programmazione per dividere il codice in blocchi con funzionalità ben distinte.

Per capire la logica di questo pattern, [32] descriviamo il funzionamento di una applicazione web (vedi Figura 1). Un client, tipicamente un browser, inoltra la richiesta ad un server per una pagina HTML. Il server ospita un’applicazione scritta in un linguaggio di programmazione lato server (come C# o PHP) che preleva i dati da un database, li elabora e li restituisce al client in formato HTML.

Figura 3: Funzionamento di un’applicazione server Fonte: https://www.html.it/pag/18299/il-pattern-mvc/

Le funzionalità di questo applicativo possono essere raggruppate logicamente in tre categorie: la prima si occuperà dei dati e fornirà quindi i metodi per accedere al database, la seconda sarà responsabile della creazione del codice HTML, mentre la terza farà da intermediario fra le prime due.

(2)

23

Se viene suddiviso il codice sorgente dell’applicativo in altrettante parti, allora si realizza il punto di forza di questo pattern come dice il sito HTML.it [32]:

«[…] lo sviluppatore, organizzando il codice secondo questo schema, potrà concentrarsi su un problema specifico ed avere la sicurezza che l’intervento rimanga circoscritto al blocco di codice di cui si sta occupando, lasciando intatti gli altri. […]»

Figura 4: Divisione dei ruoli MVC

Fonte: https://www.html.it/pag/18299/il-pattern-mvc/

Nello specifico, il pattern MVC vede la separazione dei componenti software in queste tre categorie

Model: contiene i metodi di accesso ai dati utili all’applicazione.

View: si occupa di visualizzare i dati all’utente e gestisce l’iterazione tra

quest’ultimo e l’infrastruttura sottostante.

Controller: riceve i comandi dell’utente attraverso il View e reagisce eseguendo

delle operazioni che possono interessare il Model e che portano generalmente ad un cambiamento di stato del View.

(3)

24

4.2 La root directory del framework

L’applicativo web sviluppato nel corso del tirocinio riflette la tipica struttura di un progetto Laravel.

L’immagine a fianco mostra la root directory con tutte le sottocartelle che, nell’impostazione di default del framework, sono a disposizione:

app: è quella di maggior importanza perché contiene il

core code e la maggior parte delle classi dell’applicativo. Molte funzionalità dell’applicativo trovano in questa sottocartella la loro implementazione.

bootstrap: contiene il file app.php che avvia il framework.

Contiene anche una directory cache che ospita i file generati dal framework per l'ottimizzazione delle prestazioni, come i file della cache di route e servizi.

config: come suggerisce il nome, contiene tutti i file di configurazione dell'applicazione, come quello per impostare i parametri di connessione col database. Per il progetto, sono stati impostati i parametri di connessione con PostgreSQL.

database: contiene diversi file, come le migrazioni del database, ma non sono stati

utilizzati per il progetto.

public: contiene il file index.php, che è il punto di ingresso per tutte le richieste che accedono all'applicazione e configura il caricamento automatico. Questa directory contiene anche delle risorse come immagini e gli script in JavaScript e CSS.

resources: contiene anche le view che hanno consentito l’implementazione delle mappe

del progetto.

routes: contiene tutte le definizioni di percorso dell’applicazione, per il progetto è stato utilizzato il file web.php.

storage: contiene i modelli di Blade, e altri file generati dal framework. Contiene queste

directory: app, framework e logs. La directory app può essere utilizzata per memorizzare qualsiasi file generato dall'applicazione. La directory framework viene utilizzata per archiviare

(4)

25

i file e le cache generati dalla struttura. Infine, la directory logs contiene i file di registro dell'applicazione.

test: contiene test automatici.

vendor: contiene le dipendenze del Composer. Quest’ultimo è uno strumento di Laravel

per la gestione delle dipendenze in PHP che permette di dichiarare e gestire le librerie da cui dipende il progetto.

Nei paragrafi successivi non ci si dilungherà su dettagli quali la struttura completa delle cartelle o la locazione e natura dei file di configurazione; ci si limiterà a descrivere brevemente gli aspetti principali, ovvero quelli che hanno maggiormente riguardato la realizzazione del progetto.

4.3 Le route del progetto

La figura a fianco mostra il contenuto della cartella route e il file più importante per il progetto è stato web.php perché è dove sono stati definiti i percorsi web dell’applicativo. Per ogni percorso è stata utilizzata la classe Route e il metodo get, anche se Laravel offre altri metodi e soluzioni per gestire i percorsi web.

Route::get('/map', 'MapController@queries');

Il percorso sopra serve per indirizzare alla pagina web principale dell’applicativo, cioè quando una richiesta fa match con l’URI che termina con /map, il metodo queries della classe

MapController sarà eseguito.

Route::get('/point_of_interest/{type}/{id}',

'MapController@find_point_of_interest');

In questo caso vengono catturati dei segmenti dell’URI dentro la route: type che è la tipologia del punto d’interesse scelta dall’utente per vedere le fermate più vicine e id che è l’identificativo di tale punto. Questi due parametri vengono passati al metodo

Figura 6: Contenuto della cartella Route

(5)

26

find_point_of_interest che viene eseguito quando l’utente clicca su un link presente nei popup

del marker della vista map.

Route::get('/shapes_of_route/{route_uid}', 'AjaxController@obtainShapes'); Route::get('/sections/{stop_uid}/{route_uid}', 'AjaxController@getSections'); Route::get('/all_routes/{stop_uid}', 'AjaxController@getAllRoutes'); Questi tre percorsi, invocano metodi dell’AjaxController quando l’utente clicca nei pulsanti presenti nei popup di una visualizzazione dell’applicativo web. A questi metodi vengono passati dei parametri come l’identificativo di una specifica linea roure_uid o l’identificativo di una fermata stop_uid. Verranno descritti nella sezione 5.5.

Route::get('/allschools/',

MapboxAPIController@school_coordinate'); In questo percorso, il metodo school_coordinate è servito durante la realizzazione della base di dati per modificare la tabella delle scuole e sarà descritto nella sezione 5.2.

4

.4 La cartella app

La directory che riveste maggiore importanza è senza dubbio la app contenete una gerarchia di sottocartelle e dove trovano posto:

la cartella Console in cui è possibile creare comandi Artisan personalizzati per l’applicazione. Artisan è l'interfaccia della riga di comando inclusa in Laravel che fornisce una serie di comandi utili che possono aiutare durante la creazione dell’applicazione. Infatti, è stato creato il file PopulateSections.php contenente i metodi necessari per popolare la tabella all_sections. Questa directory contiene anche il kernel della console dove i comandi Artisan personalizzati sono registrati;

(6)

27

La sottocartella Excepiton in cui lo sviluppatore può inserire i gestori delle eccezioni lanciate dall’applicazione;

 le sottoclassi del Controller, elencate nella sezione precedente, nella cartella Controller;

 le classi di Eloquent (es. Agency, CalendarDate, GeoName) che permettono, usando dei metodi specifici invocati nei metodi dei Controller, l’estrazione dei dati dal database.

4.5 La cartella public

Nella figura a sinistra è mostrata l’organizzazione della directory public. Contiene le seguenti sottocartelle:

css: come suggerisce il nome, dovrebbe contenere solo

codici in CSS. Esso è un linguaggio popolare che descrive lo stile o come dovrebbero essere visualizzati gli elementi HTML. I file map.css e bus_stop.css sono stati creati per definire gli stili delle viste dell’applicativo web. Invece, MarkerClsuter.css e

MarkerCluster.Default.css definiscono gli stili della libreria

Leaflet.markercluster [29] utilizzata per raggruppare i marker

della mappa.

img: come suggerisce il nome, dovrebbe contenere tutti i

file immagini dell’applicativo web. In questo caso, sono elencate alcune alcune icone che vengono visualizzate sulla mappa.

js: cartella contenete codici JavScript; leaflet.markercluster-src.js è il codice sorgente

dell’omonima libreria. Figura 8: La cartella public.

(7)

28

4.6 La cartella resources

La figura a fianco mostra la cartella resources dove la sottocartella più importante è la views perché contiene i codici del front-end dell’applicativo: map.blade.php e

bus_stops.blade.php.

Riferimenti

Documenti correlati

Unità Coordinamento Rete Oncologica Dipartimento Rete Oncologica Piemonte Valle d’Aosta AOU Città della Salute e della Scienza Torino... cina e rappresenti un banco di prova per gli

Devserver 17.0 disponibile sul sito: http://www.easyphp.org.

Chiamata alla funzione mysqli_stmt_bind_param() Richiede come parametri l’oggetto restituito da msqli_prepare(), il tipo dei dati e le variabili che devono essere assegnate

Responsabile | Privacy | Note legali | Monitoraggio | Archivio | Accessibilità.. Logo

I moduli di gestione autonoma dei contenuti (amministratore) consentono al cliente e/o a suo personale autorizzato, di pubblicare, modificare o eliminare in tempo reale le

Lo strumento da noi adottato ci permette di analizzare la loro distribuzione e in particolare il grafico che indica la quantità di notizie rilevate per parole chiave Manpower

Nel quadro del progetto europeo REVER MED (finanziato dall’UE con il programma INTERREG III B), avente l’obiettivo di creare una rete di percorsi verdi (greenways) dedicati ad

conveniente che il client contatti direttamente il server, vengono utilizzati degli intermediari che possono essere di vari tipi, ma tra cui il più. diffuso è il