Mokabyte

Dal 1996, architetture, metodologie, sviluppo software

  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti

Nel numero:

104 febbraio
, anno 2006

La progettazione di applicazioni web con UML

I parte: la Web Application Extension

Alfredo Larotonda
Alfredo Larotonda

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 di applicazioni web per il mercato finanziario e industriale, si occupa ora in particolare di aspetti architetturali per progetti rivolti al mercato della pubblica amministrazione. È Sun Certified Enterprise Architect (SCEA) e ha inoltre conseguito le certificazioni SCJP, SCWCD 1.3, SCWCD 1.4, SCBCD.

MokaByte

La progettazione di applicazioni web con UML

I parte: la Web Application Extension

Picture of Alfredo Larotonda

Alfredo Larotonda

  • Questo articolo parla di: Architetture dei sistemi, Java, Programmazione & Linguaggi

La Web Application Extension è l‘estensione di UML per le applicazioni web. Introduciamone i concetti fondamentali.

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.

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.

In questo esempio la nostra tabella è una classe stereotipata <

>, 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.

La classe Classe1 ha lo stereotipo <>. 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 <>. 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 <
>. 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
E‘ 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
E‘ 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
E‘ 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
E‘ 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 <>.
La servlet esegue il suo compito e delega l‘elaborazione alla pagina JSP effettuando un forward lato server, rappresentato dall‘associazione stereotipata <> con la pagina JSP PaginaJSP. Infine la pagina JSP costruisce la risposta al client generando la pagina HTML PaginaHTML2, operazione espressa dall‘associazione stereotipata <>.

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.

1Jim Conalen”Applicazioni Web con UML” II edizione italiana, Pearson Education Italia, 20032Luca Vetti Tagliati”UML e ingegneria del software: dalla teoria alla pratica”, Hops / Tecniche Nuove, 2003https://www.mokabyte.it/libri/umlbook/index.htm3Jim Arlow, Ila Neustadt “UML e Unified Process” McGraw Hill 2002

Alfredo Larotonda
Alfredo Larotonda

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 di applicazioni web per il mercato finanziario e industriale, si occupa ora in particolare di aspetti architetturali per progetti rivolti al mercato della pubblica amministrazione. È Sun Certified Enterprise Architect (SCEA) e ha inoltre conseguito le certificazioni SCJP, SCWCD 1.3, SCWCD 1.4, SCBCD.

Facebook
Twitter
LinkedIn
Picture of Alfredo Larotonda

Alfredo Larotonda

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 di applicazioni web per il mercato finanziario e industriale, si occupa ora in particolare di aspetti architetturali per progetti rivolti al mercato della pubblica amministrazione. È Sun Certified Enterprise Architect (SCEA) e ha inoltre conseguito le certificazioni SCJP, SCWCD 1.3, SCWCD 1.4, SCBCD.
Tutti gli articoli
Nello stesso numero
Loading...

Realizzare un plugin custom di Image I/O

Parte I

Service Oriented Architecture

Parte V: SOI

JasperReports: una libreria Open Source per la reportistica

Parte I

Applicazioni Desktop

Ancora su JTable

Dal RAD al Project Management: MDA non è mai stata così

Parte I: DSDM, la nuova frontiera del RAD

Nella stessa serie
Loading...

La progettazione di applicazioni web con UML

III parte: un esempio

La progettazione di applicazioni web con UML

II parte - Approfondimenti

Mokabyte

MokaByte è una rivista online nata nel 1996, dedicata alla comunità degli sviluppatori java.
La rivista tratta di vari argomenti, tra cui architetture enterprise e integrazione, metodologie di sviluppo lean/agile e aspetti sociali e culturali del web.

Imola Informatica

MokaByte è un marchio registrato da:
Imola Informatica S.P.A.
Via Selice 66/a 40026 Imola (BO)
C.F. e Iscriz. Registro imprese BO 03351570373
P.I. 00614381200
Cap. Soc. euro 100.000,00 i.v.

Privacy | Cookie Policy

Contatti

Contattaci tramite la nostra pagina contatti, oppure scrivendo a redazione@mokabyte.it

Seguici sui social

Facebook Linkedin Rss
Imola Informatica
Mokabyte