Applicazioni Web: PHP e UML

A molti programmatori, me incluso, sarà capitato senz'altro di rileggere, a distanza di tempo, programmi o segmenti di codice scritti in prima persona (senza alcun commento) e avere un iniziale senso di smarrimento. Come è possibile che non ci si capisca più nulla? È possibile, ed è la prova provata che il solo codice sorgente non è in grado di fornire una visione di insieme dettagliata e precisa, neanche agli sviluppatori stessi che quel codice l'hanno scritto.

Da queste ed altre necessità dell'ingegneria del software nasce l'idea di un qualcosa che guardi dall'alto l'intero progetto software e astragga da esso la complessità della comprensione propria del codice sorgente, la risposta a questa necessità si chiama UML.

UML è l'acronimo di Unified Modeling Language, ma "Language", in questo caso, non sta ad indicare alcun linguaggio di programmazione. Esso è in realtà un insieme di formalismi grafici che raggruppati in maniera organica forniscono un supporto visuale ed immediato ad ogni fase dello sviluppo di un progetto software Object Oriented

Nato nel 1996, grazie agli sforzi intellettuali di Grady Booch, Jim Rumbaugh e Ivar Jacobson, UMLha da subito dimostrato le potenzialità espressive della convenzione grafica a discapito di centinaia di righe di codice, imponendosi come uno standard de facto.

UML e le applicazioni Web

Considerato fino a pochi anni fa una tediosa pratica, oggi il valore dell'UML è più chiaro e il suo contributo sempre più gradito, anche a realtà piuttosto piccole. Parallelamente all'affermarsi dell'UML, il Web così come lo conoscevamo si evolveva verso la sua versione 2.0: il web moderno (fatto di PHP, Ajax, Css) porta con sé una complessità intrinseca di sviluppo molto più elevata. Come se non bastasse, in un'applicazione web importante è anche l'aspetto grafico: agli sviluppatori tradizionali lato server si aggiungeranno, quindi, gli esperti della parte grafica. Non solo, un sito web ha bisogno di ottimizzazione per balzare nei primi risultati dei motori di ricerca, agli sviluppatori e ai "grafici" si aggiungeranno i SEO.

Mentre gli sviluppatori saranno impegnati al lato squisitamente tecnico del sistema, i grafici saranno impegnati con quello artistico. Come fare dunque a garantire una pacifica convivenza a persone con bagaglio tecnico e obiettivi diversi tra loro? Risposta retorica: con l'UML! Infatti, ancor di più nelle applicazioni web, c'è bisogno di regole precise e prestabilite entro cui possono muoversi i vari ruoli. Non di meno, abbiamo bisogno di una rappresentazione che ci mostri il sistema software senza fare riferimento a dettagli tecnici che gli addetti al lato artistico della nostra applicazione potrebbero non comprendere a pieno.

Purtroppo, così come si presenta nella sua dotazione "standard", l'UML è poco adattabile al web ed è carente di rappresentazione. Fortunatamente, dalla versione 0.91, è possibile estendere le potenzialità dell'UML di base. Uno dei meccanismi di estensione più noto sono i cosiddetti stereotipi, etichette racchiuse tra parentesi angolari che arrichiscono di significato i modelli predefiniti di UML, arrivando a creare addirittura estensioni UML adatte a contesti particolari, si parlerà in questo caso di profili UML.

Il profilo di cui discuteremo nelle prossime pagine è stato proposto da Jim Conallen nel 1998 incontrando fin da subito i favori della comunità informatica, che si è prodigata in suggerimenti e consigli per migliorare il suo lavoro.

Gli articoli che seguono, vogliono illustrare brevemente ma in maniera chiara il lavoro di Jim, così da migliorare la progettazione delle nostre applicazioni Web e ottenere prodotti di qualità, requisito fondamentale per avere successo nella giungla di siti web già esistenti. Proveremo a coprire l'intero processo creativo che accompagna lo sviluppo di un'applicazione web, a partire dalla scelta dell'architettura fino alla sua implementazione. Essendo in presenza di una estensione di UML, questa serie di articoli è, di fatto, la naturale prosecuzione della guida ad UML già presente su questo sito, di cui se ne consiglia la conoscenza. Si è preferito astrarre il più possibile il resto della lettura dalle architetture, dai linguaggi e dai processi utilizzabili, per tale motivo, non verrà fatto riferimento ad alcun processo di sviluppo in particolare ma a soli princìpi generali.

L'ingegnerizzazione dell'interfaccia grafica

Come già detto poc'anzi, usabilità ed estetica sono due fattori capaci di incidere in modo significativo sul successo o meno di un'applicazione Web. Una figura che unisce il mondo dei programmatori a quello dei grafici è l'architetto dell'informazione: sua sarà la responsabilità di definire un insieme iniziali di vincoli che i due gruppi non potranno prevaricare.

L'interfaccia grafica per alcuni aspetti, è una zona molto sensibile, compito dell'architetto dell'informazione sarà disambiguare possibili incomprensioni riguardanti i seguenti argomenti:

Schermate

Consideriamo schermata l'insieme di tutti gli elementi che il browser utente mostra a video in un determinato momento. Una prima divisione degli elementi che compongono una schermata può essere fatta tra elementi statici ed elementi dinamici. I primi sono tutti quegli elementi, quali testi e immagini, codificati direttamente nel codice sorgente della pagina web (HTML, PHP, JSP e così via), i secondi sono tutti quegli elementi prelevati da basi di dati, API, feed RSS e altre fonti esterne. Ai fini della logica applicativa gli elementi statici sono praticamente trasparenti, in quanto, tali elementi non interferiranno mai con scelte architetturali o con problemi di un alto livello di astrazione. Ci concentreremo pertanto ad individuare i potenziali elementi dinamici che andranno a formare una singola schermata.

L'immagine superiore rappresenta la schermata riepilogativa di un sistema di prenotazioni online. Le schermate sono rappresentate in UML tramite una classe, su cui applicheremo lo stereotipo «screen». Il nome della classe è il nome della schermata, mentre gli elementi dinamici precedentemente identificati saranno scritti come attributi di classe. Non è necessario in questa fase raggiungere livelli di dettaglio alti, per cui non servirà individuare il tipo di dati da assegnare agli elementi dinamici. La classe di sinistra non ha molteplicità, per cui, con una singola prenotazione si può prenotare una ed una sola camera, la classe di destra, aggira questo problema utilizzando una notazione "ad array". L'inconveniente di quest'ultima soluzione è che non esistono modi "puliti" per specificare il grado di molteplicità, l'utilizzo di associazioni tra classi separate permette di raffinare la rappresentazione precedente.

In questo caso gli attributi di Prenotazione sono, esclusivamente quelli riguardanti il periodo di pernottamento, ovvero la data di arrivo, quella di partenza e il prezzo complessivo. Tutti i dettagli relativi alla camera sono rappresentati in un'altra classe. Separando i dettagli della camera da quelli della prenotazione abbiamo maggiore chiarezza, possiamo pertanto rinominare gli attributi IdCamera, NomeCamera e DimensioniCamera semplicemente in Id, Nome, Dimensioni, senza creare ambiguità. Inoltre, grazie alla possibilità di esplicitare la cardinalità, è chiaro immediatamente che per ogni prenotazione possono essere riservate da un minimo di una ad un massimo di tre camere.

Composizione di schermate

Spesso, due o più schermate, condividono elementi comuni. Ad esempio, tutte le schermate di un'applicazione web potrebbero condividere un menu laterale, oppure un piè di pagina e così via. Essendo ogni elemento, né più, né meno che semplice codice, è prassi consolidata, isolarlo e includerlo nei punti dove questo deve comparire.

Il vantaggio di tale approccio è ovvio. Se un menu compare in venti schermate e c'è bisogno di modificarlo, con questo approccio mi basta modificare l'unico elemento Menu esistente. Se invece, il codice del menu fosse codificato in ognuna delle venti schermate, andrebbe effettuata venti volte la stessa modifica. I modi per ottenere questa funzionalità sono molteplici, e vanno dalla semplice inclusione lato server ai più sofisticati design pattern presenti in vari framework. Per distinguere le schermate dagli elementi di schermata si utilizza lo stereotipo «screen compartment» al posto di «screen».

Flussi di navigazione

Con "flussi di navigazione", intendiamo l'insieme di tutti i percorsi consentiti che ci permetteranno di arrivare a una data schermata. L'immagine in basso, mostra i percorsi legali che conducono alla schermata di conferma della prenotazione. Il progettista potrà decidere il livello di astrazione che tale diagramma deve raggiungere, più alto è il livello di astrazione maggiore sarà la facilità con cui riconosceremo i percorsi.

In questo caso abbiamo due modi per raggiungere la schermata ConfermaPrenotazione, la prima comperando un pacchetto last minute tra quelli forniti, la seconda effettuando la prenotazione mentre guardiamo i dettagli delle varie camere. Per la schermata DettagliCamera si è deciso di mostrare la relazione esistente con la classe Camera, in modo da renderne nota da subito la natura dinamica. Si è preferito, invece, lasciare la schermata Offerte senza specificare altre relazioni, questo può voler significare l'assenza di elementi dinamici, oppure il tentativo di non complicare troppo il diagramma, in questo caso, una nota testuale potrebbe dire qual è il diagramma di dettaglio della schermata.

Input utente

L'input utente è un elemento fondamentale delle applicazioni web, non a caso, la differenza tra un semplice sito web ed un'applicazione web è proprio la capacità della seconda di leggere tale input e modificare di conseguenza la logica di business. In questo scenario, il ruolo di collante tra l'utente e la logica di business è svolto dai form HTML.

Per rappresentare un form HTML estenderemo la classe interessata con lo stereotipo «input form». Gli attributi di tale classe rappresenteranno i campi di input, in questa fase non serve specificare in maniera rigida il tipo di campo.

Esistono due modi, invece, per rappresentare il rapporto che un form ha con le schermate che compongono la nostra applicazione. Quando è nota a priori la schermata successiva all'invio del form è possibile utilizzare le classi associazione.

Nell'esempio precedente, è possibile prenotare una camera scegliendo esattamente i servizi desiderati grazie al form PersonalizzaPrenotazione. Non appena inviato il form, verremo condotti, sulla schermata ConfermaPrenotazione, dove sarà possibile leggere un riepilogo della prenotazione che abbiamo preparato. Qualunque sia l'input fornito la schermata di destinazione sarà sempre ConfermaPrenotazione.

Se l'input dell'utente è una discriminante nella scelta della schermata successiva, il metodo precedente non è più utilizzabile. Procederemo aggregando con una composizione il form e la schermata che lo contiene, a questo punto, dalla classe stereotipata come «input form» partiranno i flussi di navigazione alle altre schermate.

Nel prossimo articolo ci occuperemo della fase di analisi e di come le cose viste in questo articolo ci ritorneranno utili.

Dai requisiti alla fase di analisi

Sebbene con delle peculiarità, il processo di sviluppo di una applicazione web, non stravolge quello che è il processo canonico di un qualsiasi altro sistema software. Il criterio di giudizio è sempre lo stesso, tanto più la nostra applicazione realizzerà le esigenze del cliente, tanto più sarà soddisfatto. Un'applicazione bella da vedere ma che fa una cosa diversa da quella che il cliente aveva richiesto non serve a nessuno.

Per limitare incomprensioni si cercherà da subito di inquadrare, nel modo più attento possibile, quali siano i requisiti che dobbiamo soddisfare. Questa fase è detta ingegneria dei requisiti o specifica dei requisiti. Tramite interviste ai futuri utilizzatori finali (ma questo è solo uno dei tanti metodi), si cercherà di mettere nero su bianco due aspetti fondamentali: cosa l'applicazione dovrà offrire e quali vincoli dovremo rispettare.

Il primo punto rappresenta l'insieme delle funzionalità che secondo il cliente l'applicazione dovrà necessariamente fornire e sono detti requisiti funzionali, per esempio:

• L'applicazione permetterà ad un utente registrato di effettuare una prenotazione presso il nostro albergo;
• Il direttore può decidere in qualsiasi momento di attivare delle offerte last minute;

Il secondo punto raggruppa, invece, tutto ciò che non ha a che fare direttamente con le funzionalità, ma più in generale con vincoli o specifiche rigide sulla qualità del servizio, particolari tecnologie da utilizzare e misure di sicurezza da adottare (molto utile in ambito web), del tipo:

• L'applicazione dovrà essere completamente accessibile anche a utenti non vedenti;
• L'applicazione avrà una versione apposita per dispositivi smartphone;

A mano a mano che il processo di individuazione dei requisiti procede, potrebbe capitare di accorgerci che dei requisiti che sembravano funzionali in realtà non lo sono e viceversa, questo è molto comune e non è motivo di preoccupazione.

Use Case

Un modo molto utile per astrarre i requisiti funzionali è quello dei diagrammi dei casi d'uso. Un diagramma di caso d'uso rappresenta una funzionalità offerta dal sistema descritta dal punto di vista di un attore che la richiede.

Le funzionalità (le ellissi) espresse da tali diagrammi, andranno accompagnate preferibilmente da una descrizione testuale, che, senza entrare in dettagli tecnici spiega come realizzarle correttamente, quali sono le situazioni di errore, chi è l'attore che può utilizzare tale funzionalità e così via. Alistair Cockburn, propone la compilazione di apposite tabelle per organizzare in maniera organica tutte queste informazioni (si cerchi su Google cockburn template per avere un'idea di come sia strutturato tale template).

Fase di analisi

In questa fase ci si focalizza su quali saranno i requisiti funzionali da soddisfare e quali oggetti li realizzeranno. Nel paradigma OO, un oggetto è un'astrazione di un concetto del mondo reale. Negli esempi fatti fino ad ora, si è parlato spesso del concetto di camera (d'albergo). Ogni individuo se interpellato saprà esprimere in maniera soddisfacente tale concetto e di quali siano le sue caratteristiche peculiari (numero, prezzo, tipologia, dimensioni e così via).

Nel mondo informatico, la rappresentazione del concetto di una camera d'albergo è un oggetto. Come nel mondo reale, un oggetto è diverso da un altro se presenta diverse caratteristiche. L'oggetto camera23 può avere, ad esempio, come caratteristica un prezzo diverso dall'oggetto camera15. Per ogni oggetto sarà disponibile un set di istruzioni che ci permetteranno di modificare lo stato di queste caratteristiche e di realizzare i requisiti funzionali.

In questa fase si cercheranno dunque gli oggetti e le istruzioni che saranno alla base della nostra applicazione. Un buon metodo per fare un po' di luce nel buio totale della startup iniziale è quello fornito dall'euristica di Abbott, ovvero, dall'analisi testuale dei requisiti funzionali.

Euristica di Abbott

«[...], l'utente (se loggato) potrà sfogliare l'elenco delle camere libere, consultarne il prezzo, le dimensioni, i servizi ed eventualmente prenotare quella desiderata, inoltre [...]»

Questo stralcio di testo sopra, può essere visto come la specifica del caso d'uso "Prenota camera". L'euristica di Abbott, consiglia di prestare attenzione a sostantivi, verbi e aggettivi (vedi tabella per dettagli), magari sottolineandoli o evidenziandoli, in quanto, alcuni di essi, potranno essere candidabili a essere oggetti o istruzioni nel documento di analisi.

Valenza grammaticale	Significato d'analisi	Parti del testo
Sostantivo	oggetto	utente, camere
Predicato	istruzione	prenotare
Aggettivo	caratteristica	libere, prezzo, dimensioni, servizi

La distinzione non è così categorica, spesso, può capitare che un sostantivo esprima in realtà una caratteristica di un oggetto e non un oggetto vero e proprio ("prezzo", ad esempio, grammaticalmente parlando è un sostantivo, ma concettualmente è una caratteristica dell'oggetto camera e non un oggetto a sé stante). Per queste ed altre controversie basterà un po' di buon senso.

Entity, Boundary e Control

Il paradigma EBC (Entity, Boundary, Control) ci permette di fare ordine sui risultati appena prodotti dall'euristica di Abbott. Creeremo una classe per ogni oggetto o istruzione individuata, ai primi verrà aggiunto uno stereotipo <<entity>>, ai secondi aggiungeremo lo stereotipo <<control>>. Nella fase iniziale, potremmo limitarci a rappresentare le tre tipologie di classi con delle semplici icone, piuttosto che con delle classi vere e proprie.

Le entità rappresentano gli oggetti permanenti della nostra applicazione, non a caso, la nostra base di dati avrà sicuramente due tabelle per garantire la persistenza delle informazioni sulle camere. Gli elementi di tipo <<control>> sono invece le istruzioni che garantiscono la funzionalità dell'intero sistema. In futuro le "istruzioni" saranno i metodi della nostra applicazione e d'ora in poi i due termini saranno usati come sinonimi. Infine, indicheremo con <<boundary>> l'interfaccia tra la nostra applicazione e gli utenti, tipicamente le future schermate, per ora sarà comodo creare una sola classe boundary e chiamarla con il nome dato al caso d'uso: Prenota camera.

Una volta corretti eventuali errori, rivisti dettagli sfuggiti precedentemente, il diagramma può evolvere in uno più elaborato che raccoglie anche le informazioni su metodi e attributi di classe.

La collaborazione fa la forza

La complessità delle moderne applicazioni web fa sì che ogni funzionalità sia il risultato dell'esecuzione in sequenza di uno o più metodi che collaborano per un obiettivo comune. Anche le funzionalità più semplici se scrutate a fondo possono dar luogo ad un flusso operativo più o meno complesso, fatto di controlli, gestione degli errori, situazioni critiche e così via. L'immagine che segue è una rappresentazione di massima su quale sia il flusso di eventi che porta alla conclusione della funzionalità Prenota camera.

Come mostrato, può essere utile aggiungere a tale diagramma gli elementi EBC che si sono individuati al passo precedente. Se il flusso descritto dall'activity diagram sembra ragionevole, può essere rielaborato con un po' più di dettaglio arrivando così a definire un vero e proprio diagramma di sequenza. Il diagramma di sequenza, rappresenta una vista logica semanticamente equivalente al diagramma di attività, il primo però si concentra meglio sul ciclo di vita degli oggetti, sul tempo e sul meccanismo di richiesta/risposta dei vari metodi. Come per i diagrammi di classe, il progettista può decidere il livello di astrazione da conferire al diagramma di sequenza. Il consiglio è quello di non trascendere troppo in dettagli tecnici e dare al documento di analisi una visione dall'alto dell'intero sistema.

...e le pagine web?

Poco fa abbiamo detto che, era conveniente avere una unica classe <<boundary>> col nome del caso d'uso. Questo è vero, in quanto, così facendo, tutti i flussi delle classi <<control>> confluiranno tutte in un unico punto, favorendo la leggibilità del diagramma. Così facendo, però, non avremo alcuna informazione su quali saranno le schermate che parteciperanno alla realizzazione di ciascun caso d'uso. Per evitare di perdere questa informazione, definiremo una corrispondenza tra la classe <<boundary>> e le classi <<screen>> del nostro caso d'uso.

Come per altre questioni, non c'è una regola precisa su come compiere questo lavoro, in quanto può essere svolto in maniera isolata, ovvero, rappresentando in un diagramma separato l'associazione tra schermate e classi <<boundary>>, oppure, direttamente nel diagramma EBC.

Adesso che l’intero sistema dal punto di vista concettuale ha ormai una sua forma, possiamo passare a quella che viene chiamata fase di progettazione. In questa fase “sovrapporremo" idealmente il modello di analisi e i vincoli architetturali, la loro intersezione darà una istantanea di come andrà realizzato il sistema finale. Così facendo scopriremo che, ad esempio, alcuni requisiti funzionali sono irrealizzabili a causa di una determinata architettura, allora si rivedrà il documento di analisi o si modificherà l’architettura al fine di garantire una determinata funzionalità.

Sperando che nel nostro caso non ci siano problemi di questo tipo, partiremo dal diagramma delle classi e inizieremo a specializzare i singoli attributi e i singoli metodi aggiungendo tipo, visibilità, eventuali eccezioni e così via. In questa fase, può essere necessario definire delle classi di utilità, che potranno essere usate da tutte le altre classi (una classe per la connessione al database, ad esempio).

Bisognerà poi definire dettagliatamente le pagine web. Come detto precedentemente le pagine Web, sono l’interfaccia tra utente e applicazione, nostro compito sarà identificarle nella maniera migliore. Il processo si divide in due contesti, uno prettamente logico ed un altro più implementativo. Il profilo WAE definisce degli stereotipi per ogni tipologia.

Contesto logico - Pagina server

Una pagina server è una pagina i cui contenuti vengono recuperati dal server ad ogni richiesta. Ad esempio, potremmo avere una pagina server che rappresenta i dettagli di un determinato prodotto, ogni volta che viene richiamata, questa pagina, preleva dal database i dettagli del prodotto richiesto, crea l’output e lo invia all’utente. Ogni pagina server è in relazione solo con altre pagine server. All’interno dei diagrammi di classe useremo lo stereotipo <<server page>> per indicarle.

Contesto logico - Pagina client

Una pagina client contiene codice HTML e dati, non hanno bisogno di una elaborazione da parte del server, infatti quando un utente richiederà al server una pagina client, si dovrà solo individuare sul disco la risorsa giusta e mandarla all’utente.

Questo tipo di pagine possono contenere anche script di vario tipo, come ad esempio javascript, che al pari dell’HTML hanno bisogno semplicemente del browser web. Le pagine client possono essere in relazione sia con altre pagine client che con pagine server. Lo stereotipo <<client page>> identificherà questo tipo di pagina nei nostri diagrammi.

Contesto logico - Form

Un Form è una porzione di pagina client, volendo rendere il tutto molto specifico, è tutto ciò che è compreso tra il tag <form> e </form>. A causa di questo suo legame stretto con le pagine client vengono rappresentate sempre in associazione ad una pagina client. Lo stereotipo identificativo è <<HTML Form>>.

Pagine server, pagine client e form possono essere associati tra loro in modi più o meno diversi. Il modo più semplice per associare una pagina client a una pagina server può essere il semplice collegamento ipertestuale, l’associazione in questo caso la rappresenteremo con uno stereotipo <<link>>. Altri due stereotipi molto frequenti per le associazioni tra pagine sono <<submit>> e <<build>>. Il primo va da un form a una pagina server e rappresenta materialmente quello che è l’invio dei dati dal client al server che si occuperà di gestire i dati passati. Il secondo mostra esplicitamente la creazione della pagina client di output, a partire da una pagina server. L’utilizzo di una pagina client, oltre che la pagina server, ci permette di osservare quali sono le funzionalità demandate al client. La figura sottostante rappresenta il funzionamento del form di prenotazione di una camera.

Contesto implementativo - Pagina dinamica

Le pagine dinamiche sono quelle che realizzeranno materialmente le pagine server. La richiesta partirà da un browser e potrà essere utile anche per generare del codice HTML da mostrare all’utente finale sottoforma di pagina client. Lo stereotipo da utilizzare in questo caso è <<dynamic page>>.

Contesto implementativo - Pagina statica

Una pagina statica può realizzare solo pagine client e non ha nessuna collaborazione con il server, al momento che verrà richiamata dal browser, il server invierà una copia esatta del documento all’utente senza svolgere alcun tipo di elaborazione. Lo stereotipo utilizzabile in questo caso è <<static page>>

Il contesto implementativo ci permette di esplicitare il legame tra i file fisici residenti sul server e le astrazioni del contesto logico. Sebbene la differenza tra pagina client e pagina statica nonché tra pagina dinamica e pagina server può sembrare inutile col passare del tempo diventerà molto più netta e ne capiremo i vantaggi. Nell’immagine successiva grazie alla aggiunta della pagina dinamica prenotazioni.php, è facile capire quale componente gestisce materialmente il funzionamento del form di prenotazione rappresentato in figura 1.

Adesso quello che manca alla quadratura del cerchio è stabilire con precisione come sono legate le interfacce alle pagine statiche/dinamiche del nostro progetto. Come già detto precedentemente questo lavoro è fondamentale per garantire la buona coesistenza tra grafici e sviluppatori. Se il progetto è affrontato in maniera coerente avremo la possibilità di dare agli sviluppatori il controllo del codice e ai grafici la possibilità di richiamare le funzioni sviluppate.

Il metodo è stato spiegato negli articoli precedenti, quello che cambia in questa fase è il maggior dettaglio che dovremo implementare nei diagrammi.

Ora che tutto è stato deciso fin nei minimi dettagli, possiamo finalmente mettere mano al codice, partendo dalle classi sviluppate, creeremo le definizioni dei vari metodi e attributi, dopodiché, sequenze alla mano, li svilupperemo.

Questo articolo chiude la serie, la difficoltà dei primi tempi andrà via via diminuendo all’aumentare della pratica, si troveranno così soluzioni personalizzate all’ottimizzazione del lavoro. Buona progettazione a tutti.