Framework – Introduzione e classificazione

In rete si trovano sempre più applicazioni, che vengono messe a disposizione degli utenti sotto forma di applicazioni web da aprire dal browser. Rientrano tra gli esempi classici di questo tipo i web mailer o i giochi per il browser. Anche nel contesto aziendale si è affermato il modello di licenza Software as a Service: ci sono applicazioni web per i processi CRM (Customer Relationship Management), per il sistema di gestione della merce, per newsletter, per la pianificazione dei progetti, per la registrazione del tempo di lavoro dei dipendenti o per la contabilità. Proprio le piccole aziende traggono maggior vantaggio da modelli economici orientati alle proprie esigenze e da una disponibilità centrale su Internet. Così i costi per la gestione e l’amministrazione sono ridotti, e si gode anche della massima flessibilità, visto che non si è legati ad una specifica piattaforma o ad un dispositivo in particolare.

Per sviluppare le applicazioni web, i programmatori ricorrono generalmente ai framework. Ma di che cosa si tratta? E che cosa rende un framework così speciale per le applicazioni web?

Con framework (in italiano: struttura o intelaiatura) si intende la struttura di un programma che viene utilizzata come base nello sviluppo software. Se uno sviluppatore volesse scrivere un nuovo programma, sarebbe inefficiente dover ricominciare ogni volta da zero. Per numerose funzioni standard nello sviluppo software esistono soluzioni già pronte sotto forma di codice. Nella programmazione orientata agli oggetti vengono utilizzate soprattutto classi, che vengono integrate come progetto per lo sviluppo degli oggetti. Un framework rappresenta spesso una collezione di diverse classi collegate tra di loro e stabilisce così la struttura di base del design di ogni software, che viene sviluppata a partire dal framework. Se un framework serve come struttura di base delle applicazioni web, si parla di framework per applicazioni web (in inglese: web application framework).

Come base per lo sviluppo software, i framework dovrebbero mettere a disposizione strutture chiare, gestibili facilmente e che consentono agli sviluppatori di creare in poco tempo applicazioni web funzionanti. Per soddisfare questo requisito, molti framework si basano su tre principi di base del design:

• Don’t repeat yourself (DRY): il principio Don’t repeat yourself mira ad evitare la ripetizione nell’ambito dello sviluppo software. Le informazioni ridondanti, quali ad esempio duplicati di codici, sono tendenzialmente evitabili e si riflettono negativamente sulla gestione del software. Se devono essere adattate stringhe di codice ridondanti, le modifiche devono essere apportate in diversi punti del codice del programma.

• Keep it short and simple (KISS): ad ogni problema corrisponde una soluzione. È questo il principio base del paradigma KISS, che si orienta sulla regola della parsimonia. Se per una questione si trovano più soluzioni, si deve scegliere quella che abbia il numero minore di ipotesi e variabili, quindi si dovrebbe riuscire ad utilizzare un framework o a risolvere uno specifico problema utilizzando il minor codice possibile.

• Convention over Configuration: più si configura qualcosa, più dispendiosa sarà la sua gestione. Invece, le convenzioni offrono una possibilità di ridurre la complessità. I framework dovrebbero infatti stabilire un metodo grazie alle impostazioni standard e offrire altre possibilità di configurazione opzionali.

Se questi principi del design vengono presi in considerazione, l’uso di framework fornisce moltissimi vantaggi nell’ambito dello sviluppo software. Ma le istruzioni di un framework impostano anche limiti agli sviluppatori, che possono quindi diventare degli svantaggi.

Utilizzando un framework, si risparmiano tempo e costi nello sviluppo software. L’idea di base è il riutilizzo del codice, cosa che si riferisce soprattutto alle funzionalità essenziali come connessioni database, template delle pagine, processi di caching o funzioni di sicurezza, messi a disposizione dai framework come elementi già preimpostati del codice. Così il lavoro di sviluppo si limita ad uno specifico codice del programma di una nuova applicazione web. Visto che la maggior parte dei framework vengono offerti gratuitamente, di solito non sussistono costi per la realizzazione.

Inoltre i framework supportano la generazione di un codice sorgente corretto, visto che gli sviluppatori possono ricorrere a componenti già verificati per quanto riguarda le funzioni standard. Le parti dei programmi messe a disposizione dai framework sono sottoposte il più delle volte a numerosi cicli di sviluppo e vengono ottimizzate continuamente. La community svolge così la funzione di tester e co-sviluppatore. In caso di progetti grandi, le falle di sicurezza dei nuovi componenti vengono scoperte e risolte velocemente. Uno scambio tra utenti e sviluppatori avviene generalmente nei forum del progetto, che sono in parte moderati dai team di supporto.

In rete si trovano un numero quasi illimitato di framework per lo sviluppo web, che si differenziano sia per quanto riguarda i design pattern sia relativamente alla gamma di funzioni. Diversi progetti di software possono così richiedere l’uso di vari framework. Gli sviluppatori si trovano davanti ad un enorme scelta e così devono scegliere il framework più adatto alle loro esigenze. Ben presto si giunge però a compromessi, facendo in modo che il progetto del software desiderato si adatti ai limiti del framework. Visto che i framework sono progettati come soluzioni universali, è raro che gli sviluppatori utilizzino tutte le funzioni della struttura preimpostata. A seconda della sua varietà di funzioni, un’applicazione comprende perciò più codice di quanto sia necessario, quindi in questo caso sarà presente del codice superfluo.

Rientra tra gli svantaggi anche il fatto che agli sviluppatori viene consigliato di rivolgersi ad uno specifico produttore o ad una community di sviluppatori in particolare per utilizzare al meglio un framework. In alcuni casi l’uso di un framework è legato a precise condizioni di licenza. Inoltre possono sorgere dei problemi, se è previsto che possa essere ulteriormente sviluppato.

Visto che inizialmente gli sviluppatori devono prendere confidenza con la struttura del rispettivo programma e le possibilità di utilizzo, si presuppone un periodo iniziale di adattamento, sempre relativo, se si pensa a quanto tempo verrà comunque risparmiato grazie a funzioni già pronte e agli elementi costitutivi del codice. Qui i critici vedono però il rischio che le conoscenze di base vadano perdute. Infatti gli utenti che programmano esclusivamente sulla base di framework, si confrontano probabilmente in maniera meno intensiva con i linguaggi di programmazione utilizzati.

Dato che il codice sorgente della maggior parte dei framework è disponibile liberamente, in linea di massima tutti possono prendere confidenza con queste strutture. Se le applicazioni da usare nelle aziende vengono sviluppate sulla base di elementi di codice disponibile liberamente, questi risultano possibilmente più trasparenti per gli hacker rispetto alle app che dispongono di un codice sorgente proprietario.

Come i framework in generale, anche i framework per applicazioni web vengono delimitati dalle librerie dei programmi (libraries) e i tool di sviluppo web (Web Development Tools). Mentre le librerie mettono a disposizione solo alcune funzionalità, un framework può essere considerato come una struttura interattiva del programma per processi standard, cioè quasi come un’applicazione semi-automatica.

I componenti principali di un framework sono costituiti da classi collegate tra di loro a cui sono assegnati dei metodi. Si tratta di blocchi di codice, che descrivono le proprietà degli oggetti e il loro comportamento. Alcuni di questi componenti sono statici e quindi immutabili, mentre altri possono essere adattati dagli utenti, ad esempio tramite la sovrascrittura di metodi. In questo modo si ha la possibilità di modellare la struttura del programma ad uno specifico compito. I componenti flessibili di un framework prendono anche il nome di “Hot spot”, mentre le parti statiche vengono invece chiamate “Frozen spot”.

I framework seguono di solito il pattern Inversion of Control (IoC) (in italiano: inversione di controllo). Si può descrivere come un’applicazione basata sul principio di Hollywood della programmazione orientata agli oggetti: “Don’t call us, we call you!“ (traducibile in italiano come “Non chiamarci, ci faremo risentire noi!”).

Spiegato in maniera semplice, IoC significa che la responsabilità per l’esecuzione dei programmi non risiede nei singoli componenti che vengono sviluppati ed eseguiti sulla base del framework, ma si trova nel framework stesso. Così ricopre la funzione di un programma principale, che coordina il flusso di controllo. Altri componenti che vengono implementati nel framework e quindi registrati, sono a sua disposizione in caso di necessità. Questo funzionamento si può comparare con un classico congedo per un casting ad Hollywood: “Sappiamo chi sei e ti ricontatteremo non appena avremo bisogno di te!”.

Per poter eseguire queste funzioni di controllo principali, i framework hanno preimpostata un’interfaccia utente specifica, che deve essere implementata da tutti i componenti costituenti. Tramite questo principio del design, il framework è sempre in grado di portare i componenti costituenti ad implementare i metodi di callback, che gli consentono, se necessario, di iniettare le informazioni nei componenti o di attivare un comportamento preciso tramite l’uso di metodi. Mentre le classi e le loro relazioni nei classici approcci dello sviluppo software vengono codificati e quindi stabiliti già in fase di compilazione, il metodo inversione di controllo di un software consente di generare gli oggetti in modo dinamico durante il runtime.

Nello sviluppo software IoC ricopre la funzione di una strutturazione generale e viene azionato da alcuni design pattern, come Dependency Injection (DI) e Dependency Lookup.

La maggior parte dei framework per applicazioni web si basa su un pattern architetturale, che prende il nome di Model-View-Controller (MVC). Il suo obiettivo è quello di operare una netta divisione dalla logica di applicazione e dal livello di presentazione, oltre che suddividere i software nella fase di sviluppo in tre ambiti, cioè Model (i dati), View (la presentazione dei dati) e Controller (qualunque interazione dell’utente).

• I dati: il Model è la parte di un framework che comprende i dati da visualizzare, la logica di applicazione e le regole. I processi, come richiamare i dati e apportare modifiche, si svolgono grazie a metodi previsti appositamente. 

• Presentazione dei dati all’utente: il compito essenziale del View è la visualizzazione dei dati messi a disposizione dal Model. Per questo il View interroga lo stato del Model tramite metodi e viene informato sempre dal Model sulle modifiche. Un altro compito del View è quello di accettare i comandi dell’utente (immissioni dalla tastiera, click del mouse) e inoltrarli al Controller.

• Interazione dell’utente: il Controller svolge la funzione di interfaccia tra Model e View. Così gestisce una o più Views, valuta gli input dell’utente e reagisce di conseguenza, ad esempio consegnando i dati al Model o predisponendo le modifiche al View.

L’obiettivo del modello MVC è quello di creare un programma flessibile. La separazione della logica di applicazione e del livello di presentazione dovrebbero semplificare i processi per apportare modifiche successive, attivare estensioni e permettere il riutilizzo dei singoli componenti. Così si riduce ad esempio il lavoro di programmazione, per adattare il software a diverse piattaforme (Windows, Mac, Linux) o per utilizzarlo come web app, perché solo il Controller e il View devono essere adattati di conseguenza.

Esiste anche il JSP (Java Server Pages) che si basa sul pattern MVC e viene utilizzato per la programmazione web in Java. Così una pagina JSP corrisponde al View, una servlet al Controller e una Java Bean al Model.

Il mercato delle applicazioni web è molto variegato. Le app, che sono disponibili per gli utenti dal browser, si differenziano a seconda del campo di utilizzo e dello spettro di funzioni, non solo per le dimensioni e le sembianze, ma anche essenzialmente nel design del software. Motivo di ciò è la varietà dei framework disponibili, che si appoggiano a differenti tecnologie e seguono diversi approcci nel design del software. Si possono contrappore approcci Single-Page e Multi-Page, lato server e lato client, oltre che framework che si basano su azioni o sui componenti.

Le applicazioni Multi-Page sono composte da più pagine HTML, che solitamente vengono aperte tramite l’inserimento del rispettivo URL nel browser e sono collegate tra loro tramite hyperlink (collegamenti ipertestuali). L’interfaccia utente di un’applicazione Single-Page invece è composta solo di una pagina HTML su cui sono impostati tutti gli input dell’utente. Si può suddividere in pannelli, cursori o schede di registrazione. Per quanto riguarda la navigazione, l’URL di un’applicazione Single-Page rimane invariato.

Il modello di programmazione delle web app classiche corrisponde a quello del World Wide Web, la cui architettura è basata sul protocollo di trasferimento di un ipertesto (HTTP, Hypertext Transfer Protocol). Se un’applicazione web viene richiamata da un utente, sono coinvolti in ogni caso uno o più server o client, come ad esempio un browser. A seconda di come viene progettata la comunicazione tra server e client, si parla di applicazioni lato server o lato client.

• Applicazioni lato client: se all’avvio di un’applicazione viene caricata l’intera interfaccia utente HTML comprensiva di logica di applicazione nel client, si parla di applicazioni lato client. Le modifiche all’interfaccia, per via degli input dell’utente, vengono in questo caso impostate tramite linguaggi di programmazione lato client, come JavaScript. Si consiglia un approccio del design di questo tipo per le app in cui gli utenti lavorano per un periodo di tempo più lungo sulla stessa visualizzazione, perché solo i dati visualizzati sull’interfaccia utente vengono ricaricati dal server. L’approccio lato client viene utilizzato prima di tutto per lo sviluppo di app Single-Page e viene usato da framework JavaScript, come AngularJS o EmberJS.

• Applicazioni lato server: nelle applicazioni lato server, la logica di applicazione rimane sul server, che crea l’interfaccia utente e invia al client i dati per la visualizzazione. Per le modifiche all’interfaccia utente sono a disposizione così i linguaggi di programmazione lato server e lo sviluppo è completamente indipendente da possibili vulnerabilità del client. Questo approccio viene utilizzato solitamente nelle app Multi-Page, in cui le diverse visualizzazioni delle pagine, se necessario, vengono richiamate dal server. Un design del software di questo tipo è però collegato con tempi di caricamento più lunghi, ma riduce le richieste fatte sul dispositivo client. Su alcune app si evita di memorizzare la logica di controllo per motivi di sicurezza. Un’applicazione dell’approccio lato server si trova ad esempio nei framework Django, Zend e Ruby on Rails.

Un approccio di programmazione lato server si trova soprattutto nei framework, che sono stati sviluppati per la creazione di applicazioni web classiche con struttura Multi-Page e con un’interfaccia utente classica HTML. Solo l’interfaccia viene visualizzata nell’applicazione web e utilizza solitamente la navigazione del browser. Le web app di questo tipo si possono eseguire indipendentemente dal sistema operativo o dal browser utilizzati. La logica di controllo viene elaborata tramite la comunicazione tipica, elaborata dal server tramite documenti HTML, basata sul modello Request/Response.

Le applicazioni web lato client vengono anche denominate Rich Client o Rich Internet Application (RIA). Le applicazioni di questo tipo implementano l’interfaccia utente comprensiva di logica di applicazione nel client, che viene generalmente caricata completamente all’avvio. A differenza delle applicazioni web classiche, si possono impostare con un approccio lato client anche proprietà conosciute maggiormente per le applicazioni desktop, come il controllo tramite drag&drop, la disponibilità dei contenuti in modalità offline e l’accesso all’hard disk.

Al livello del controllo delle applicazioni, i framework si dividono in due classi. Mentre i framework basati sulle azioni (action-based) riproducono lo schema Request-Response tipico del protocollo HTTP, ci si discosta da questo procedimento nei framework basati sui componenti (component-based).

I framework basati sulle azioni: nei framework basati sulle azioni, il Controller serve come istanza centrale, che accetta le richieste del client, le convalida e richiama l’azione corrispondente. Per ogni possibile azione deve essere creato dallo sviluppatore app preventivamente un oggetto, che comprende la corrispettiva logica di applicazione, derivabile solitamente dalle classi astratte. Se l’azione viene portata a termine, il Controller aggiorna il Model e inoltra il risultato al View, che a sua volta crea la risposta e la rinvia al client.

I framework basati su azioni fanno affidamento sul modello MVC e, per via della stretta applicazione dello schema Request-Response, vengono denominati anche request-based. Dei tipici esempi per questo tipo di framework sono:

• Django

• Ruby on Rails

• Symfony

• Spring MVC

• CodeIgniter

Visto che le possibili azioni di un framework basato sulle azioni vengono definite dettagliatamente dallo sviluppatore app, si parla di un approccio White Box, che dà agli sviluppatori maggiori libertà. È richiesta però una comprensione più profonda del framework in uso, dato che gli sviluppatori sono responsabili per la creazione di pagine HTML, CSS e JavaScript.

I framework basati sui componenti: a differenza dell’approccio controllato tramite azioni, i framework controllati dai componenti si discostano dallo schema Request-Response del protocollo HTTP, dove l’interfaccia utente di un’applicazione web viene considerata come una collezione di componenti. Per ognuno di questi componenti, che sono collegati con oggetti lato server, vengono definite precise reazioni durante lo sviluppo delle applicazioni web, che si susseguono ad eventi, causati da un’interazione utente con il componente. Si parla perciò anche di framework controllati da eventi. Dei tipici esponenti di questo tipo di framework sono:

• Lift

• Apache Tapestry

• JavaServer Faces

• Apache Wicket

L’idea di base dietro ad un approccio basato sui componenti è quella di raggruppare le azioni correlate. Un componente AccountController rappresenta ad esempio azioni come login, logout o getAccount. Un oggetto può così essere responsabile per molte più azioni. I framework basati sui componenti offrono solitamente una grande scelta di componenti riutilizzabili, che nascondono agli sviluppatori di app i dettagli dello schema Request-Response alla base. Si parla in questo contesto di un modello Black Box. I framework di questo tipo sono quindi particolarmente utili per gli sviluppatori che vogliono appoggiarsi prima di tutto a componenti predefiniti. Chi vorrebbe avere maggiori libertà per quanto riguarda il protocollo HTTP e i linguaggi HTML, CSS e JavaScript, farà meglio ad indirizzarsi su un framework basato sulle azioni.

Visto che i framework hanno una grande influenza sulle funzioni e sulle possibilità di strutturazione delle applicazioni web, nonché sulla fase di sviluppo, il processo di lavoro comincia solitamente già con la scelta della struttura di base del programma appropriato. Così dovreste considerare da una parte l’intento del software programmato, ma anche le conoscenze già acquisite.

Le domande principali da porsi riguardano il tipo di applicazione e l’architettura desiderata (lato server, lato client). Entrambi gli aspetti hanno effetti diretti sulla navigazione e l’usabilità di una web app.

Per la ricerca del framework adatto rappresentano un punto da cui partire anche le conoscenze di programmazione che già si possiedono e la disponibilità dell’infrastruttura necessaria. Specialmente tra i linguaggi di programmazione largamente diffusi, come PHP (ad esempio Zend, Symfony, CakePHP o CodeIgniter), Java (ad esempio JavaServer Faces o Apache Wicket) o Python (come Django), c’è un’ampia scelta di framework ben documentati. La popolarità di Ruby nello sviluppo web è soprattutto riconducibile alla diffusione del popolare framework Ruby on Rails. I framework lato client si basano solitamente sul linguaggio di scripting JavaScript.

Gli sviluppatori che in passato hanno programmato prima di tutto applicazioni desktop, trovano spesso difficile il modello di programmazione orientato sullo schema Request-Response dei framework basati sulle azioni, rispetto agli sviluppatori web classici. In questo caso un framework basato sui componenti può essere la soluzione migliore per cominciare ad avvicinarsi a questo tipo di strutture.