Introduzione
Sviluppare software oggi con metodi tradizionali è estremamente complesso, tali e tante sono le diverse tecnologie disponibili. Le nuove applicazioni vengono costruite utilizzando disparate tecnologie e hanno frequentemente l'esigenza di interfacciarsi con altre applicazioni. Proprio in tale ambito e con l'obiettivo di prevenire e gestire al meglio la maggior parte delle problematiche che comunemente si riscontrano in ambito sviluppo, nasce la Model Driven Architecture (MDA nel seguito). Nei successivi paragrafi, dopo aver esaminato in modo introduttivo tali problematiche, la metodologia MDA verrà presentata, descrivendone vantaggi e benefici proprio con riferimento alle problematiche medesime.

Sviluppare software oggi - i maggiori inconvenienti: il problema della produttività
Il processo di sviluppo del software, così come è attuato oggi, è spesso costituito da progettazione effettuata a livello basso e gran parte dell'enfasi data all'attività di codifica.
Un tipico processo (si veda la figura 1) è caratterizzato dalle seguenti fasi:

1. Acquisizione dei Requisiti e Concettualizzazione
2. Analisi e Descrizione Funzionale
3. Progettazione
4. Codifica
5. Test
6. Messa in Esercizio

Figura 1 - Processo di Sviluppo del Software nell'approccio tradizionale

L' attività di produzione documentazione - corredata di eventuali diagrammi - viene svolta durante le prime tre fasi. Il tutto resta comunque allo stato di "artifatti" cartacei. Ogni volta che è necessario apportare modifiche alla applicazione, esse vengono effettuate a livello codice, non c'è mai il tempo necesssario per rendere la documentazione allineata con la applicazione.
Questo in effetti è stato uno degli elementi trainanti che hanno fatto nascere la filosofia XP (Extreme Programming), proprio basata sul fatto che le attività di codifica e testing sembrano essere le più produttive.
Come osserva poi Alistair Cockburn in Agile Software Development, i problemi nascono quando il team originario di sviluppo viene smembrato, e quello attuale che deve effettuare manutenzione evolutiva e correttiva si trova dinanzi a decine di migliaia di linee di codice senza sapere da dove incominciare: come trovarsi in una città sconosciuta senza una mappa!

Il problema Portabilità
Periodicamente, l'industria del software "sforna" nuove tecnologie, che si diffondono con estrema rapidità - si pensi a Java, Linux, XML, SOAP, UML, J2EE, .NET, JSP, Flash, Web Services e a quanto rapidamente, subito dopo il loro apparire, si sono affermate.
Molte aziende sono portate a seguire l'evoluzione delle tecnologie per diverse (valide!) ragioni, ad esempio perchè è il cliente finale a richiederle, oppure perchè alcune di esse risolvono brillantemente alcune problematiche (si pensi a XML per l'interscambio dati e a Java per la portabilità).
Questo fatto impone alle aziende medesime di rivolgere la loro attenzione alle nuove tecnologie, facendo diminuire, come logica conseguenza, il valore degli investimenti fatti precedentemente su altre, divenute ormai obsolete.

Il problema Interoperabilità
Praticamente nessun sistema software oggi è pensato per operare in condizioni di isolamento. Nel corso degli anni, si è gradualmente abbandonala la filosofia della applicazione "monolitica", andando sempre di più verso lo sviluppo di realtà software "component-based", proprio per garantire quanto più possibile una maggiore semplicità di sviluppo, e anche di successiva manutenzione. Risulta evidente pertanto come un'applicazione da sviluppare ex-novo debba necessariamente prevedere di essere interfacciata con altri sistemi, generalmente preesistenti.

Il problema Manutenzione e Documentazione
La maggior parte degli sviluppatori considera lo sviluppo del codice il proprio task principale. Scrivere documentazione durante l'attività di sviluppo costa fatica e rallenta l'attività stessa. Inoltre, poter disporre di una documentazione di buona qualità viene visto come un qualcosa mirato al futuro e al mantenimento del progetto, e non ad un ritorno immediato.
Queste sono alcune delle motivazioni che spiegano perchè la documentazione prodotta è raramente di buona qualità......per non parlare del fatto che andrebbe poi modificata a mano ogni volta che viene modificato il codice!!!
Ecco perchè linguaggi OO quali Java o Eiffel, che permettono di generare automaticamente documentazione strettamente legata al codice (e pertanto sempre necessariamente allineata con esso) presentano, in tal senso, caratteristiche estremamente interessanti.

La Model Driven Architecture - Concetti generali
La Model Driven Architecture è una metodologia estesa per lo sviluppo del software definita da Object Management Group (http://www.omg.org).
MDA nasce con lo scopo preciso di affontare e risolvere le diverse problematiche presentate nel precedente paragrafo.
Concetto centrale di MDA è quello di modello, definito da MDA come una rappresentazione di una parte di una funzionalità, struttura o aspetto comportamentale di un dato sistema.

La modellazione diviene pertanto l'attività trainante durante il processo di sviluppo del software.
Come si può notare nella figura 2, non ci sono - apparentemente - grosse differenze rispetto a quanto visto nella precedente figura 1.

Figura 2 - Processo di Sviluppo del Software nell'approccio MDA

Nel caso attuale, tuttavia, i diversi "artifatti" creati durante il processo di sviluppo non sono cartacei, ma piuttosto modelli formali, ossia modelli comprensibili anche da strumenti automatici.
In particolare, MDA definisce tre tipologie fondamentali di modelli:

Platform Independent Model (PIM)
Come dice la parola stessa, si tratta di un modello completamente indipendente da ogni implicazione tecnologica. All'interno di un PIM, il sistema viene modellato catturando le sole informazioni di business e servendosi di un formalismo che sia adeguato a rappresentarle nel modo migliore, tipicamente l'UML.

Platform Specific Model (PSM)
Durante la successiva fase, il PIM viene trasformato in uno o più PSM, ciascuno specifico degli elementi che caratterizzano una determinata tecnologia.
Per esempio, un PSM dedicato alla tecnologia EJB conterrà concetti e costrutti tipici del mondo EJB, perciò troveremo all'interno di esso termini quali "home interface", "entity bean", "session bean".
Analogamente, un PSM dedicato al mondo DBMS conterrà elementi quali "tabella", "colonna", "foreign key".
Per rappresentare un PSM, verranno utilizzati degli stereotipi UML particolari e specifici per quella determinata tecnologia.

Code Model
La fase finale vede la trasformazione di ciascun PSM nell' insieme dei componenti software corrispondenti. Dato che ciascun PSM è strettamente legato alla tecnologia cui fa riferimento, trasformare un PSM nel corrispondente codice è un passo relativamente diretto.
La metodologia MDA definisce i modelli PIM, PSM e Code, e inoltre definisce le modalità con cui ciascun modello deve essere trasformato nel successivo.
Da quanto detto, risulta chiaro che il passo più complesso risulta essere quello che trasforma un PIM nell'insieme dei PSM richiesti. Molti sono i tool disponibili sul mercato in grado di effettuare trasformazioni da PSM a Codice, e non c'è nulla di particolarmente innovativo in questo.
Proviamo d'altra parte a pensare a quanto (prezioso) tempo costa la realizzazione di una struttura di dati o di un framework EJB a partire da un progetto espresso in termini di business.
L'ideale sarebbe poter disporre di un tool in grado di permetterci di costruire, a partire da un PIM, i relativi PSM e il conseguente codice, consentendo allo sviluppatore di tenere costantemente sotto controllo l'intero processo di sviluppo, e di validare continuamente sul codice via via prodotto gli effetti di quanto modellato nei diversi PSM, così come in ambito PIM.

Di cosa abbiamo bisogno per implementare il processo MDA in pratica?
La risposta è: dei cosiddetti MDA Building Blocks, vale a dire:

• una serie di modelli di alto livello, costruiti servendosi di un formalismo standard e ben definito, e che siano coerenti, dettagliati e completi
  
• un formalismo standard e ben congegnato per poter definire tali modelli
  
• una serie di regole di trasformazione per ottenere i necessari PSM, a partire da un dato PIM. Esse costituiscono un punto critico, data la loro complessità, e devono essere adattate alle esigenze degli utenti finali così come delle tecnologie impiegate
  
• un linguaggio formale per poter scrivere tali definizioni, immediatamente interpretabile da appositi tool di trasformazione
  
• uno o più tool di trasformazione che implementano le diverse trasformazioni descritte e, idealmente, permettano di intervenire sui singoli step effettuandovi fine tuning
  
• un tool di trasformazione da PSM a codice, per arrivare a una applicazione completa

Vantaggi e benefici
L'adozione di MDA porta con sè una evidente serie di vantaggi, proprio in riferimento alle problematiche trattate più sopra.In particolare, rispettivamente:

Il problema Produttività
Seguendo l'approccio suggerito da MDA, il focus dello sviluppatore si sposta verso lo sviluppo del PIM. Pur essendo evidente che definire in modo corretto e completo la trasformazione verso i diversi PSM è alquanto complesso, si tratta di una attività che, effettuata una volta per tutte, può essere riapplicata in diversi contesti.
Il fatto stesso che la maggioranza degli sviluppatori debba preoccuparsi ora della definizione del PIM, aumenta drasticamente la produttività per almeno due ragioni:

• lavorare a livello PIM significa non doversi preoccupare dei dettagli tecnici e tecnologici che si troveranno sotto - a livello PSM.
• Il PIM è un modello di business, e come tale ad esso - e ad esso solo- dedicato. Ciò porta con sè il fatto che si tratta di un ambito molto più vicino alla realtà così come richiesta dall'utente finale, che porterà quindi a sviluppare meglio e in meno tempo

È chiaro che un simile notevole aumento della produttività può ottenersi laddove si riesca a reperire uno strumento in grado di automatizzare totalmente la trasformazione di un dato PIM nei differenti richiesti PSM. Inoltre, intervenire per le modifiche sui modelli di livello più alto, oltre ad essere più semplice, contribuisce a rendere allineato tutto il processo di sviluppo.
I modelli di alto livello in questo caso non sono più soltanto cartacei, si tratta bensì di oggetti direttamente correlati con il codice generato, e completamente coerenti con esso.

Il problema Portabilità
Un PIM è, per definizione, un modello indipendente dalla tecnologia, e pertanto sempre valido, prescindendo dalla tecnologia che di volta in volta viene impiegata per costruire i relativi PSM. Tutto ciò che viene specificato a livello PIM è pertanto completamente portabile.
Il problema in tal caso, sarà reperire appositi tool che permettano di trasformare un dato PIM nei diversi richiesti PSM, e specifici per la tecnologia di quel particolare PSM.

Il problema Interoperabilità
Come mostrato in figura 3, l'insieme dei diversi PSM generati a partire da un PIM può avere interrelazioni.

Figura 3 - Interoperabilità in ambito MDA

Esse, in ambito MDA, sono denominate bridges.
Per costruire un bridge, occorre trovare una corrispondenza tra gli elementi caratteristici di un dato PSM e quelli caratteristici di un altro PSM.
MDA definisce anche le regole di costruzione di tali bridges.
Per fare un esempio, si pensi di avere già definito in modo stabile un PIM.
Si deduca da questo un PSM dedicato al mondo relazionale, e lo si chiami PSM-dbms.
È quindi possibile individuare in modo univoco a quali elementi del PIM fanno riferimento determinati elementi del PSM-dbms.
Dal medesimo PIM si derivi ora un diverso PSM, specifico per il mondo EJB, e lo si chiami PSM-ejb. Si individui, anche in questo caso, una corrispondenza tra gli elementi del PIM e quelli corrispondenti in PSM-ejb.
A questo punto basta mettere in corrispondenza l'insieme degli elementi di PSM-dbms con i corrispondenti elementi in PSM-ejb: ecco il bridge.
È chiaro che una completa interoperabilità a livello cross-platform sarà ottenuta una volta reperiti appositi tool che siano in grado di generare non solo i richiesti PSM a partire da un dato PIM, ma anche i relativi bridges tra essi e verso altre piattaforme.
Solo in tale maniera gli investimenti fatti a livello PIM verrano, nel tempo, completamente salvaguardati.

Il problema Manutenzione e Documentazione
Lavorando con MDA viene prodotto un PIM, da cui derivato un insieme di PSM, da cui poi derivato il codice.
In tal senso, il PIM costituisce una rappresentazione, ad alto livello e costituita da modelli, del codice stesso, e costituisce la migliore fonte di documentazione, sempre e costantemente allineata e aggiornata con il codice prodotto.
Ciò anche in quanto ciascun tipo di intervento evolutivo viene apportato a livello modelli (PIM e PSM) rendendo la modifica in questione propagabile anche agli altri livelli.
Anche in questo, si nota come sia importante scegliere tool in grado di preservare e mantenere tutte le relazioni esistenti tra PIM e PSM.

Conclusioni
Si è visto come la Model Driven Architecture sia nata proprio per far fronte alla esigenza di approcciare in modo integrato le diverse problematiche delle sviluppo di applicazioni, permettendo di tenere sempre sotto controllo l'intero processo, anche e soprattutto in vista delle attività di manutenzione evolutiva e correttiva che verranno apportate nel seguito.
Nella prossima parte, verrà descritto in dettaglio un esempio concreto, a partire dalla fase di raccolta dei requisiti di business, con l'obiettivo di mostrare, passo dopo passo, come l'applicazione della MDA permetta di abbattere i tempi di sviluppo globali e di raggiungere una qualità complessiva di quanto viene prodotto molto più elevata.

Bibliografia
[1] Anneke Kleppe, Jos Warmer, Wim Bast - "MDA Explained: the Model Driven Architecture - Practice and Promise", Booch Jacobson Rumbaugh, 2003
[2] Alistair Cockburn - "Agile Software Development", Cockburn - Highsmith Series Editors, 2002
[3] Model Driven Architecture - http://www.omg.org/mda/
[4] Architecture Board ORMSC - "Model Driven Architecture", OMG document, ormsc/2001-07-01, 2001
[5] Wim Bast - "Delivering on the Essence of MDA", Compuware White Paper Series, 2004