Introduzione
Nella parte I del presente articolo, si è visto come le diverse problematiche che si incontrano nel processo di sviluppo del software possano essere affrontate in modo integrato utilizzando la Model Driven Architecture (MDA nel seguito), la metodologia definita da Object Management Group (http://www.omg.org/mda/).
MDA prevede la definizione di tre tipologie di modelli, un Platform Independent Model (PIM nel seguito) avente lo scopo di catturare i requisiti di business del sistema da sviluppare, un insieme di Platform Specific Model (PSM nel seguito), ciascuno specifico per una data tecnologia e contenente elementi atti a rappresentarne le particolari caratteristiche, e un Code Model, destinato a contenere tutto il codice che viene sviluppato derivandolo dai diversi PSM di cui al passo precedente.
Nei successivi paragrafi verrà mostrato, su un caso reale, in quale modo l'adozione di MDA permetta di rendere lo sviluppo di un progetto estremamente più efficace, diminuendo sensibilmente tempi e costi, e permettendo di raggiungere una qualità complessiva di quanto viene prodotto molto più elevata.

Analisi e modellazione
Per mostrare come possa essere impiegata in pratica la metodologia MDA, vediamo in dettaglio un esempio concreto, tratto dalla vita reale, e quindi non banale.
Si partirà dalla modellazione di un sistema caratterizzato da un PIM relativamente semplice per osservare poi come è possibile pervenire a una serie di PSM relativamente complessi, base per la successiva produzione del codice.
Per chi fosse interessato ad avere maggiori dettagli, l'esempio in questione è ampiamente trattato su http://www.klasse.nl/mdaexplained, da cui è possibile anche scaricare una versione demo.

Business requirements
Obiettivo del nostro business è la realizzazione di un completo sistema di composizione e consegna a domicilio di colazioni. Il generico cliente si connette al sito Web della azienda responsabile potendo scegliere, tra le differenti tipologie previste di colazione, quella preferita, e indicando poi data, ora e luogo richiesti per la consegna, oltre al proprio numero di carta di credito. Nell'ambito delle possibilità di scelta che ha il cliente sono previsti differenti tipi di colazioni, da quelle standard a quelle per occasioni speciali, a quelle tipiche di una determinata nazione, e quindi dotate delle varie specialità previste (uova e bacon su quella Inglese, succo di arancia e croissant su quella Francese, decorazioni speciali su quella per il giorno di S. Valentino o di Natale ecc.).
Ciascuna di tali colazioni è disponibile in formato simple, grand e deluxe.
Due volte alla settimana viene effettuato l'inventario di quanto disponibile in magazzino per le diverse preparazioni, fatta salva l'esigenza di approvigionamento di prodotti quali il pane fresco, che va acquistato giornalmente. Come ulteriore facility, ciascun cliente ha la possibilità di personalizzare ulteriormente la propria richiesta, potendo ad esempio decidere, a partire da una determinata colazione-base, di aggiungere o togliere determinati alimenti, come pure di modificare la quantità richiesta di altri.

L'applicazione software
Pur comprendendo perfettamente che a questo punto sarà venuto al lettore un certo languorino, occorre ricordare che il nostro principale interesse è incentrato sulle caratteristiche del sistema software destinato a implementare il business descritto. L'obiettivo finale è quello di produrre una applicazione web-based di tipo J2EE three-tier costituita da un DBMS, uno strato mid-tier EJB e una interfaccia utente costituita da JSP. L'applicazione sarà dotata di due differenti interfacce, una per i clienti, l'altra per le persone che lavorano nella azienda fornitrice di colazioni, per avere tutte le necessarie informazioni sul tipo di ordine da evadere e consegna da effettuare. Se il cliente è d'accordo, le sue generalità verranno conservate nel sistema, cosa che permetterà di riconoscere i clienti abituali e di praticare eventuali sconti. Quando un cliente abituale si connetterà al sistema, una lista di ordini già effettuati verrà mostrata, con l'opzione di ripeterli. Il DBMS manterrà le informazioni sui clienti: nome, prezzo e contenuti per ogni tipo di colazione offerta.

Applicare MDA - Trasformazioni
Nella figura 1 sono riportati tutti gli elementi del business oggetto del nostro studio. Si può notare come, data l'esigenza di avere tre differenti tecnologie a livello applicativo, si debbano costruire tre differenti PSM, operando tre differenti trasformazioni, e cioè in particolare:

• una trasformazione dal PIM a un modello relazionale al fine di ottenere, a partire da un modello formale del PIM - espresso in UML - un modello espresso in termini di diagramma ER (Entity-Relationship)
• una trasformazione dal PIM a un modello EJB al fine di ottenere, a partire da un modello formale del PIM - espresso in UML - un modello espresso in termini di una variante di UML che utilizzi stereotipi particolari per EJB
• una trasformazione dal PIM a un modello Web al fine di ottenere, a partire da un modello formale del PIM - espresso in UML - un modello espresso in termini di una variante di UML che utilizzi stereotipi particolari per l'interfaccia Web

Figura 1 - Applicazione pratica di MDA
(clicca sull'immagine per ingrandire)

Successivamente, per passare dai tre PSM ai corrispondenti Code Model, sarà necessario poter disporre di:

• una trasformazione dal modello PSM relazionale agli elementi SQL corrispondenti
• una trasformazione dal modello EJB PSM relazionale al codice Java corrispondente
• una trasformazione dal modello Web PSM relazionale ai corrispondenti elementi JSP e HTML

Dettaglio sul PIM
Diamo uno sguardo più dettagliato al PIM costruito per modellare il nostro sistema di gestione e consegna colazioni.

Tale modello è stato costruito servendosi del formalismo UML ed è rappresentato in figura 2.

Figura 2 - PIM del sistema di gestione e consegna colazioni
(clicca sull'immagine per ingrandire)

Si noti in particolare come ciascuna colazione (StandardBreakfast) contenga un certo numero di Parti (Part), ciascuna delle quali, a sua volta, indica la quantità di ciascun genere alimentare (Comestible) presente in quella determinata colazione. Il prezzo di ciascuna colazione viene calcolato sulla base del formato prescelto e del prezzo della colazione standard selezionata. Il prezzo complessivo dell'ordine viene ottenuto sommando ai prezzi dei singoli componenti la colazione una quota per la consegna. Si noti che il modello rappresentato definisce il sistema di gestione e consegna colazioni indipendentemente da qualsiasi particolare tecnologia.
In tal senso, è un Platform Independent Model (PIM).

Implementazione pratica: utilizzare un tool MDA
Nel presente paragrafo vediamo un esempio di realizzazione pratica dell'applicazione sopra descritta.
Per realizzare il sistema richiesto è stato impiegato lo strumento OptimalJ di Compuware (http://www.optimalj.com o anche http://javacentral.compuware.com per maggiori dettagli), proprio in virtù della sua caratteristica peculiare, e cioè di essere un tool che supporta completamente MDA.
Nella figura 3 viene riportato il modello UML disegnato per implementare il PIM sin qui discusso.

Figura 3 - Modello UML del PIM
(clicca sull'immagine per ingrandire)

Nella successiva figura 4 si può notare come, a partire dal modello UML visto precedentemente, vengano automaticamente generati i corrispondenti PSM per i tre layer DBMS, EJB e Web.

Figura 4 - Generazione dei PSM
(clicca sull'immagine per ingrandire)

È questo un passo particolarmente importante e delicato, giacchè essere in grado di derivare, a partire da un PIM, ossia un modello puramente logico, tanti diversi PSM quante sono le differenti tecnologie prescelte, ciascuno arricchito di tutti gli elementi che gli sono caratteristici, è un processo tutt'altro che banale.
Nella figura 4 è anche visualizzato il Web Diagram, ossia il diagramma delle dipendenze tra gli elementi del web tier (in verde) e quelli dell'EJB tier (in arancio).
A questo punto, il passo successivo consiste nell'effettuare una opportuna trasformazione che, a partire da quanto contenuto nei diversi PSM, derivi tutti i componenti software necessari a costituire l'applicazione completa.
Per quanto descritto precedentemente, tale passo è relativamente diretto, dato che i diversi PSM contengono già tutti gli ingredienti necessari e sufficienti alla costruzione del relativo codice.
Nelle successive figure sono riportati alcuni dettagli di quanto generato.
Scegliendo come elemento di riferimento nel PIM la classe Customer, vediamo nei diversi PSM cosa è stato generato. In particolare:

PSM EJB - Nella figura 5 abbiamo un dettaglio del codice dell'Entity Bean relativo all'elemento Customer.

Figura 5 - Dettaglio di Entity Bean generato
(clicca sull'immagine per ingrandire)

PSM Web - Nella figura 6 è possibile visualizzare uno dei componenti generati a partire dal web component Customer, nel nostro caso si tratta di una Action Class, ossia di uno di quei componenti Java demandati, nell'ambito di determinati scenari architetturali (MVC Struts, nella situazione in esame, cfr [5]) ad eseguire le diverse azioni che l'utente richiede a partire dalla GUI visualizzata nel browser. Nel caso riportato in figura, in particolare, l'azione svolta è quella di browse sul Customer

Figura 6 - Customer Browse Action Class
(clicca sull'immagine per ingrandire)

PSM DBMS - Nella figura 7 è riportato il diagramma E-R della applicazione in corso di sviluppo

Figura 7 - Entity Relationship Diagram
(clicca sull'immagine per ingrandire)

mentre nella figura 8 si può esaminare anche uno dei diversi SQL script generati automaticamente al fine di permettere la gestione delle tabelle nel DBMS scelto per il deploy della applicazione. Nel caso riportato in figura il DBMS scelto è Oracle - senz'altro uno dei più diffusi e affidabili - e lo script riportato è quello di Create Tables

Figura 8 - ORACLE SQL Script Create Tables
(clicca sull'immagine per ingrandire)

È chiaro che questo tipo di artifatti prodotti nel PSM DBMS non servono nel caso in cui si tratti di lavorare con un DBMS preesistente, per il quale non avrà senso pensare di utilizzare script di creazione tabelle.

Il codice che è stato generato rispecchia fedelmente tutto quanto è stato modellato nel PIM e successivi PSM da esso derivati. Si può inoltre notare come, durante ciascun passaggio di trasformazione - dal PIM ai PSM e dai vari PSM al Code - ogni elemento di un layer costituisca base per la costruzione di numerosi elementi nel layer successivo (corrispondenza 1-n): ad es., con riferimento alla classe Customer del PIM, ad essa corrispondono n elementi nel PSM EJB, n elementi nel PSM Web, n elementi nel PSM DBMS.

Analogamente, da ciascuno di essi viene derivato un insieme di componenti software (notare ad es. in figura 5, il numeroso insieme di "generated files" corrispondenti ad un singolo elemento del PSM EJB).
Tutto ciò evidenzia una importantissima caratteristica di MDA, e cioè l'elevata capacità di astrazione: è sufficiente lavorare su un elemento di un layer per influenzare
automaticamente le caratteristiche di tutti gli elementi ad esso corrispondenti del layer sottostante.

L'applicazione risultante può a questo punto essere compilata ed eseguita, e permette di effettuare tutte le operazioni base sulle diverse tabelle che costituiscono il database del sistema (si veda, a titolo esemplificativo, la figura 9)

Figura 9 - Main Menu della Applicazione Base
(clicca sull'immagine per ingrandire)

È chiaro d'altra parte che l'applicazione in questione non rappresenta affatto qualcosa di pronto per essere consegnato agli utenti finali perchè mancheranno, in generale, tutta una serie di funzionalità che devono ancora essere aggiunte.
Come procedere allora?

Modifiche all'applicazione generata - L'approccio White Box
L'applicazione base vista in figura 9 è ancora lontana dal poter essere consegnata agli utenti finali. Allo stato attuale essa costituisce un semilavorato completamente funzionante, coerente e ben organizzato, ma pur sempre un semilavorato.
Nascono allora tutta una serie di quesiti:

• Come si può modificare l'applicazione sin qui ottenuta, intervenendo su quanto presente?
• Come posso aggiungere nuove funzionalità?
• E se voglio aggiungere del codice Java scritto ad hoc?
• Come si può avere garanzia di allineamento tra le diverse parti nei diversi modelli se alcune di esse vengono modificate?
• E la documentazione?

Queste sono solo alcune delle diverse possibili numerosissime domande che possono venire in mente.
Proviamo a dare una risposta valida per tutte? MDA, naturalmente.
La Model Driven Architecture ci permette, in ogni momento, di intervenire sul semilavorato scegliendo, a seconda dei casi e della esperienza dello sviluppatore, il layer più idoneo ad effettuare la modifica (evolutiva o correttiva) richiesta, di qualunque natura essa sia.
In tal modo, il semilavorato può essere via via arricchito nei propri modelli (PIM, PSM e Code) fornendo, in ogni momento, piena garanzia di allineamento tra tutte le sue parti, e facendo, di conseguenza, evolvere l'applicazione generata, secondo un meccanismo di approssimazioni successive che giustifica in pieno la locuzione white box con cui è possibile contrapporsi alla filosofia black box, così tipica di quegli strumenti CASE che, a suo tempo, videro fallire i propri obiettivi, proprio in virtù della loro rigidità d'uso.

Alcuni esempi
Solo a titolo di esempio e senza la pretesa di essere esaustivi, dati anche i limiti imposti dallo spazio a disposizione, proviamo a fornire alcune idee su come affrontare, in ambito MDA, modifiche del tipo di quelle descritte più sopra.

Come si può modificare l'applicazione sin qui ottenuta, intervenendo su quanto presente?
Dipende dal tipo di modifica. Occorre prima di tutto decidere su quale layer effettuarla, tenendo conto del fatto che più "in alto" si va, in termini di astrazione, più semplice sarà intervenire. Se ad esempio desideriamo che un dato campo su una JSP sia visualizzato con determinati attributi (colore rosso e testo bold, ad esempio), si potrà senz'altro pensare ad una proprietà da specificare in ambito PSM Web.

In tal caso, converrà definire la proprietà in questione come elemento a sè stante. Successivamente, basterà mapparla su tutti quegli attributi ai quali si intenda assegnarla.
In figura 10 è riportato un semplice esempio di definizione della proprietà, che viene poi messa in corrispondenza con l'attributo AccountNumber di Customer.

Figura 10 - Modellare una modifica sul web tier
(clicca sull'immagine per ingrandire)

Un altro esempio potrebbe essere costituito dalla esigenza di definire un metodo di ricerca (finder method) su un campo diverso dalla chiave primaria. Anche in tal caso si opera a livello PSM, ma stavolta sul layer EJB.
Si veda in figura 11 un esempio, in cui si è definito un finder method sull'attributo AccountNumber di Customer.
Anche in questo caso, la funzionalità da implementare è stata semplicemente modellata.

Figura 11 - Modellare una modifica sull' EJB tier
(clicca sull'immagine per ingrandire)

Altri tipi di modifiche possono suggerire un intervento a livelli più alti, ad esempio a livello PIM.
Nel prossimo esempio verrà illustrata una situazione di questo tipo.

Come posso aggiungere nuove funzionalità? E se voglio aggiungere del codice Java scritto ad hoc?
Si pensi alla esigenza di definire sul cliente una operazione di Creazione Ordini.
Un possibile approccio può consistere nel definire, a livello PIM (sempre su Customer) una Operation, da modellare definendone tipo di ritorno e parametri (vedere figura 12).

Figura 12 - Modificare il PIM - Creazione di una Operation
(clicca sull'immagine per ingrandire)

Una Operation a livello PIM a cosa corrisponde nei livelli PSM sottostanti? Il successivo passo di trasformazione si occupa proprio di questo, e pertanto dovrà creare:

PSM Web: una web action appartenente all'elemento Customer (ricordiamo che secondo le specifiche J2EE una web action è la formalizzazione di una qualunque interazione con l'utente). Sarà poi possibile inserire il proprio codice Java nelle zone pre e post - figura 13

Figura 13 - Web Action sul PSM Web
(clicca sull'immagine per ingrandire)

PSM EJB: un business method appartenente all'elemento Customer. Anche in questo caso sarà possibile intervenire scrivendo il proprio codice Java nell'apposito spazio, al fine di implementare il metodo di business modellato al passo precedente - figura 14

Figura 14 - Business Method sul PSM EJB
(clicca sull'immagine per ingrandire)

Come si può avere garanzia di allineamento tra le diverse parti nei diversi modelli se alcune di esse vengono modificate?
I tool che implementano MDA e' previsto che siano in grado di mantenere costantemente aggiornati tutti i diversi modelli (PIM, PSM, Code), e ciò allo scopo di avere garanzia di coerenza tra le diverse modifiche apportate e gli artifatti via via generati tramite le differenti trasformazioni. La figura 15 illustra appunto tale fondamentale passo di sincronizzazione (update) tra i diversi layer.
Come risultato di tale step, tutte le modifiche effettuate a livello PIM e PSM vengono a sincronizzarsi tra di loro, rendendo sempre completamente coerenti ntra di loro tutte le sue parti.
Un successivo passo di Generate Code permette infine di produrre tutta la parte di codice conseguente a quanto presente nei diversi PIM e PSM.
Il risultato finale sarà, ancora una volta, una applicazione completa (rispetto allo stato dell'arte dei modelli) e completamente funzionante, sulla quale intraprendere la successiva iterazione di modifiche, e così via, fino al raggiungimento dello stato finale della applicazione pronta per essere consegnata.

Figura 15 - Sincronizzazione attiva tra PIM, PSM e Code
(clicca sull'immagine per ingrandire)

La documentazione
Nella prima parte del presente articolo si è evidenziato come anche il problema di avere in ogni momento una documentazione allineata con l'applicazione possa essere risolto seguendo l'approccio MDA.
Fonte principale di documentazione è proprio il modello di business (PIM), proprio in virtù del fatto che esso cattura tutti i requisiti di business del sistema da sviluppare e ne costituisce una rappresentazione completa e costantemente allineata - a patto, naturalmente, che si utilizzi un tool MDA, che mantenga costantemente aggiornato il PIM con tutti gli artifatti dei layer sottostanti.

Nasce allora l'idea di combinare le caratteristiche in tal senso "native" di Java - e cioè la funzionalità di Javadoc che permette di produrre automaticamente la documentazione di progetto - con le caratteristiche proprie del PIM, e cioè, tanto per essere concreti, con il diagramma UML che formalizza il nostro PIM.
Sempre utilizzando il tool OptimalJ, siamo in grado di produrre un enhanced Javadoc, vale a dire un package di documentazione Javadoc arricchito del diagramma (o dei diagrammi) di interesse, tra tutti quelli sviluppati nel corso del progetto.
Nella figura 16 si può vedere un esempio di Javadoc generato in formato HTML arricchito col diagramma UML del PIM oggetto del nostro studio.

Figura 16 - Enhanced Javadoc
(clicca sull'immagine per ingrandire)

Conclusioni: il futuro di MDA
Si è visto come applicare in modo estensivo MDA al ciclo di sviluppo di una applicazione software permetta di raggiungere elevati livelli di produttività e di qualità.
Tuttavia, al tempo della stesura di questo articolo, MDA viene ancora considerata immatura.
Viene quindi naturale porsi domande sul futuro di MDA, e su quali tendenze potrebbero emergere in seno ad essa.
Non è possibile, ad oggi, dare una risposta definitiva, tuttavia è possibile individuare alcune aree chiave per i futuri sviluppi, e cioè:

• sviluppo completo di linguaggi MDA compliant, in virtù del fatto che ad oggi la maggior parte delle specifiche OMG per descrivere modelli si sofferma maggiormente sugli aspetti statici dei linguaggi utilizzati (attraverso il MOF meta-model, cfr [6]), nel senso che manca totalmente la parte semantica dinamica dei linguaggi stessi. Si pensi a descrivere ad esempio il comportamento di un automa a stati servendosi del formalismo MOF. Ad oggi, MOF non è completo e pertanto una trattazione dinamica della attività di un tale automa non è possibile
• modalità e metodologie di astrazione più raffinate sui modelli, man mano che le esperienze sul campo diverranno sempre più significative. L'esigenza sarà allora di arricchire sempre di più le potenzialità espressive dei modelli al fine di essere in grado di produrre "artifatti" sempre più sofisticati (si pensi ad aree quali il riuso di astrazioni, in modo da rendere possibile ereditare e combinare variamente template, pattern, package, si pensi ad architetture complesse, i cui blueprints possano poi essere diffusi al fine di creare sistemi completamente coerenti, solo per citare alcuni esempi)

Utilizzare MDA in pratica significa cambiare radicalmente il proprio modo di approcciare le attività di sviluppo di un sistema software, significa capovolgere il focus sino ad ora saldamente ancorato all'attività di codifica, per imparare, prima di tutto, a pensare agli aspetti del business che si intende affrontare, prima ancora che ai dettagli tecnologico-applicativi.
Significa scegliere, come affermato sul sito web di OMG, una "Architettura per un mondo in continua evoluzione".

Bibliografia
[1] Java Community Process "UML Profile for EJB" - http://www.jcp.org/en/jsr
[2] Jon Siegel & the OMG Staff Strategy Group - "Developing in OMG's Model Driven Architecture", OMG document, 01-12-01, 2001
[3] King's College London - "An Evaluation of Compuware OptimalJ Professional Edition as an MDA Tool", University of York, 2003
[4] Compuware Lab "OptimalJ Community" - http://javacentral.compuware.com
[5] Web Tier Application Framework Design - http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html
[6] Meta Object Facility (MOF) Specification, 1999