Introduzione
Con questo articolo iniziamo una breve serie dedicata alla progettazione delle applicazioni web con UML. Le problematiche legate alle metodologie di sviluppo e all’utilizzo di UML come linguaggio per la modellazione di sistemi object-oriented sono ampiamente affrontate ed esaminate in letteratura per cui non ci soffermeremo tanto su questi aspetti, ma ne faremo un breve accenno introduttivo per entrare nell’argomento oggetto della serie, la progettazione di applicazioni web. Vedremo quali sono gli strumenti che UML ci mette a disposizione per assolvere a questo difficile compito e daremo qualche esempio concreto di utilizzo.

Il ciclo di sviluppo del software e la progettazione
Parlare di metodologie per la produzione del software richiederebbe una discussione vasta e approfondita. In bibliografia ci sono riferimenti a testi che parlano diffusamente ed egregiamente dell’argomento [3].
La produzione del software è di per sé un ambito nel quale ancora esiste molto dibattito e molta confusione. In alcune realtà , neanche tanto rare, non esistono metodologie per la produzione del software che avviene per così dire in maniera ‘artigianale’. Questo a mio parere è dovuto ad una serie di fattori, alcuni legati alla specificità intrinseca del ‘prodotto’ software altri a ragioni culturali.
Il software è di per sé un prodotto immateriale la cui qualità è difficile da percepire da parte di un cliente. Nessuno acquisterebbe un’automobile o una casa sapendo che questa non è il risultato di una precisa progettazione fatta da personale altamente qualificato e preparato.
Nel software invece questo non sempre avviene poiché spesso l’unica percezione del cliente è che il prodotto ‘funzioni’, il che di per sé significa abbastanza poco. Ciò è dovuto alla concezione del tutto errata che la produzione del software non possa avvenire secondo un ciclo produttivo standardizzato nel quale la scrittura del codice è solo uno dei passi, sicuramente importante ma non il più importante.
Uno dei passi fondamentali nel ciclo di sviluppo del software è la progettazione, oggetto del nostro articolo. La progettazione è quella fase in cui le astrazioni del sistema da realizzare, evidenziate nella fase di analisi, assumono concretezza e portano a produrre un risultato ‘fisico’ che sono i componenti software che costituiscono la realizzazione del sistema stesso.

Le applicazioni web e UML
Le applicazioni web sono sistemi ad oggetti che hanno alcune peculiarità. L’interfaccia utente è un internet browser e la comunicazione tra il cliente ed il server avviene tramite il protocollo http. Le architetture delle applicazioni web possono essere le più disparate. Un’ottima descrizione delle varie possibilità è in [1]. In ogni caso si farà riferimento ad applicazioni strutturate secondo il pattern MVC (Model-View-Controller) in base al quale l’applicazione viene suddivisa in tre livelli logici distinti corrispondenti al presentation, al controllo e alla logica dell’applicazione.
Una buona progettazione deve interessare ciascuno dei livelli, anche se erroneamente si tende a sviluppare modelli di classi ed oggetti solo per la parte di logica tralasciando in fase di progettazione l’interazione tra view e controller che invece ha un notevole impatto sul risultato a livello di utente finale e di sistema.
Indipendentemente dalla metodologia utilizzata per lo sviluppo del software e dalla parte del sistema che si vuole progettare, il linguaggio per rappresentare i modelli del nostro sistema è UML , Unified Modelling Language. UML è divenuto lo standard per la modellazione di sistemi ad oggetti ed è ormai molto diffuso e conosciuto. UML non è una metodologia, ma è un linguaggio con la sua semantica e la sua sintassi che serve a rappresentare, in una maniera standard e condivisa da tutti, i modelli che rappresentano le astrazioni del nostro sistema software. E’ bene puntualizzare che adottare UML senza avere una metodologia di sviluppo è come acquistare un macchinario senza avere un ciclo produttivo in cui questo macchinario possa assolvere al suo compito.
Un’ottima descrizione di come UML possa essere utilizzato nell’ambito della metodologia più utilizzata al momento, lo Unified Process, la si può trovare in [3].
Quello su cui ci soffermeremo è come con UML si possano rappresentare alcuni elementi specifici delle applicazioni web in fase di progettazione. UML di per sé non fornisce strumenti per la rappresentazione di una pagina html piuttosto che di una pagina JSP. A questo punto si colloca il lavoro di Jim Conallen, l’ideatore della Web Application Extension.

La Web Application Extension
La WAE , come la chiameremo d’ora in avanti, consente di rappresentare in termini di classi ed oggetti le pagine web, oltre ad altri elementi del modello di una applicazione web importanti quanto le classi che appartengono al livello di business.
Per fare ciò è stato sfruttato il meccanismo di estensione tipico di UML. Gli ideatori di UML hanno giustamente previsto la possibilità di estendere la semantica del linguaggio affinché questo potesse adattarsi allo sviluppo tecnologico tipico di questo ambito e quindi essere più longevo.
E’ possibile quindi definire nuovi elementi del linguaggio UML estendendo quelli già presenti tramite il meccanismo degli sterotype, dei tagged value e dei constraints.
Gli stereotipi sono delle estensioni del significato di un elemento del linguaggio UML.
Ad esempio tutti conoscono come in UML si rappresenta una classe; un rettangolo diviso in sezioni che riportano il nome della classe , i suoi attributi e i suoi metodi come in Figura 1.

Figura 1 – Una classe in UML

Per rappresentare una tabella di un db relazionale in UML si può utilizzare lo stesso simbolo della classe ma estendone il significato, ovvero nella terminologia UML associandole uno stereotipo di tipo table. Lo stereotipo è indicato sopra il nome della classe racchiuso tra <<>> o con un icona diversa come in Figura 2.

Figura 2 – Una tabella relazionale come classe con stereotipo table>>

In questo esempio la nostra tabella è una classe stereotipata <<table>>, i suoi attributi sono le sue colonne e i suoi metodi delle stored procedure.
I tagged value consentono di estendere le proprietà di un elemento del linguaggio. La classe ha le sue proprietà di base, per aggiungerne di nuove si possono definire nuovi tagged value.
I constraint invece sono quelle condizioni alle quali deve soddisfare un elemento del modello per essere considerato valido.
L’insieme di questi meccanismi ci consente si estendere UML e rappresentare le pagine web nel nostro modello di progettazione.

Stereotipi fondamentali per le classi nelle applicazioni web
Nella Figura 3 sono rappresentate le classi con gli stereotipi principali utili alla progettazione di applicazioni web.

Figura 3 - Stereotipi fondamentali della WAE

La classe Classe1 ha lo stereotipo <<client page>>. Rappresenta una pagina client, ovvero la pagina HTML interpretata dal browser internet del client. La pagina client è frutto nelle applicazioni web dell’elaborazione di una pagina server e può contenere codice Javascript, file css e altri elementi che vedremo come rappresentare in UML.
La classe Classe2 ha invece stereotipo <<server page>>. E’ una pagina server , quindi nel mondo J2EE sarà realizzata da una pagina JSP. Una pagina server è una pagina dinamica il cui codice viene eseguito lato server e interagisce con gli altri elementi del sistema. Al termine della sua elaborazione può inviare una risposta al client che consiste in una pagina client.
La Classe 3 ha stereotipo <<form>>. Rappresenta un form HTML e quindi come attributi avrà i vari elementi di input del form.
Queste classi stereotipate non hanno vita a sé stante nel modello ma saranno sicuramente collegate in qualche modo. La WAE definisce anche alcuni stereotipi per le associazioni.

Stereotipi fondamentali per le associazioni nelle applicazioni web
Gli stereotipi fondamentali per le associazioni che servono a rappresentare i legami tra le classi stereotipate nella WAE sono i seguenti:

build è il legame tra una pagina server ed una client. La pagina server ‘costruisce’ la pagina client
link E’ il legame tra una pagina client ed una risorsa lato server o tra una pagina client ed un’altra pagina client. Corrisponde ad un href in terminologia HTML.
forward è il legame che esiste tra due pagine server quando l’una delega l’elaborazione all’altra. E’ ad esempio il forward lato server tra una servlet ed una JSP.
submit èil legane tra un form html ed una pagina server o un’altra risorsa server come una servlet. Il form effettua il submit dei campi di input contenuti al suo interno.
include èil legame di inclusione che può esistere tra una pagina server ed un’altra pagina server nel caso ad esempio di include dinamiche, o tra una pagina server ed una client come nel caso di include statiche.

Con le classi stereotipate viste in precedenza e con quelle che vedremo nel prossimo articolo e con le associazioni elencate si possono rappresentare efficacemente le interazioni e la struttura degli elementi di una applicazione web quali pagine html, pagine JSP, form etc.. che comunemente vengono tralasciate in sede di progettazione.
C’è da precisare che quanto visto ha a che fare con componenti logici indipendenti dalla piattaforma. Quindi una server page sarà realizzata nel mondo J2EE da una Java Server Page mentre ad esempio nel mondo .NET da una pagina ASPX. La WAE è applicabile ad entrambi gli ambiti.
Un esempio di utilizzo di classi stereotipate ed associazioni è in Figura 4 in cui viene raffigurata l’interazione tra una pagina HTML , una servlet ed una pagina JSP tipica delle applicazioni web J2EE.
Si noti come la pagina HTML PaginaHTML1 contenga un form HTML rappresentato dalla classe stereotipata Form1 che ha una relazione di aggregazione stretta con la classe stereotipata PaginaHTML1. L’associazione tra form HTML e servlet Servlet1 è di tipo <<submit>>.
La servlet esegue il suo compito e delega l’elaborazione alla pagina JSP effettuando un forward lato server, rappresentato dall’associazione stereotipata <<forward>> con la pagina JSP PaginaJSP. Infine la pagina JSP costruisce la risposta al client generando la pagina HTML PaginaHTML2, operazione espressa dall’associazione stereotipata <<build>>.

Figura 4 - Rappresentazione dell'interazione tra pagine client e risorse server

Questo semplice esempio ci da l’idea di come in fase di progettazione sia semplice rappresentare la struttura della parte web e come sia efficace ed immediata questa rappresentazione.
Nel prossimo articolo vedremo un esempio di un caso reale nel quale rappresenteremo anche altri elementi come classi stereotipate.

Conclusioni
In questo articolo abbiamo introdotto la Web Application Extension di UML ideata da Jim Conallen. La WAE ci consente di rappresentare in modo agevole ed efficace gli elementi tipici di una applicazione web quali pagine client, pagine server , form html. Nel prossimo articolo vedremo come utilizzando la WAE si possano combinare classi stereotipate ed associazioni stereotipate per rappresentare le interazioni di questi elementi nella progettazione delle applicazioni web.

Bibliografia
[1] Jim Conalen - "Applicazioni Web con UML", II edizione italiana – Pearson Education Italia, 2003
[2] Luca Vetti tagliati - " UML ed ingegneria del software: dalla teoria alla pratica ", Mokabyte, 2000
[3] Jim Arlow, Ila Neustadt – “UML e Unified Process” – McGraw Hill , 2002 [biografia autore] Alfredo Larotonda, laureato in Ingegneria Elettronica, lavora da diversi anni nel settore IT. Dal 1999 si occupa di Java ed in particolare dello sviluppo di applicazioni web J2EE. Dopo diverse esperienze di disegno e sviluppo ora si occupa in particolare di aspetti architetturali per progetti rivolti al mercato finanziario ed industriale. E’ un Enterprise Architect certificato Sun Microsystems (SCEA) ed inoltre ha conseguito le certificazioni SCJP, SCWCD 1.3, SCWCD 1.4, SCBCD.