Untitled Document
   
 
MDA... buona idea, ma con qualche dubbio...
di Dan HayWood - traduzione di Mario Giammarco

MDA in breve
L'obiettivo di OMG con MDA è quello di permettere agli sviluppatori di applicazioni di concentrarsi sul determinare i requisiti aziendali dell'applicazione, evitando di preoccuparsi di quale particolare piattaforma tecnologica realizzerà questi requisiti. In altre parole, l'applicazione è specificata e implementata in maniera indipendente dalla piattaforma. La dichiarazione di OMG è che i sistemi sviluppati in questa maniera dovrebbero avere un ciclo di vita molto più lungo delle piattaforme sottostanti; 20 anni sono suggeriti come valore tipico.

La parte centrale di MDA è il Platform Indipendent Model (PIM), modellato in UML. Vari cambiamenti sono stati introdotti in UML 2.0 per supportare specificatamente MDA; fra questi ricordiamo il Precise Action Semantics che può essere utilizzato per descrivere il comportamento.

Mentre PIM è indipendente dalla tecnologia il Platform Specific Model (PSM) è quello dove "la gomma si scontra con l'asfalto". Ai fornitori spetta il compito di utilizzare mapping e trasformazioni per convertire un dato PIM in uno o più PSM. MDA non prescrive come questa cosa può essere realizzata, ma indica che usualmente le trasformazioni possono essere da modello a modello oppure da meta-modello a meta-modello. Più concretamente, diversi fornitori usano dei tag o altri tipi di meta-dati per annotare i PIM in maniera che vari PSM possano essere generati.

Un PIM può derivare multipli PSM per due differenti ragioni. Per prima cosa possono esserci diversi PSM se l'applicazione nella sua interezza (p.e. Un programma di elaborazioni testi) deve girare su differenti sistemi operativi e piattaforme. Aggiungiamo inoltre che, se nasce una nuova piattaforma durante il ciclo di vita dell'applicazione è possibile definire un nuovo mapping e portare l'applicazione su questa nuova piattaforma. Per seconda cosa, che è anche conseguenza della prima, MDA è adatto per sviluppare sistemi distribuiti che sono composti di varie parti che girano su differenti piattaforme e livelli. Per esempio, ci può essere un livello web implementato su ASP.Net ma che parla ad un livello intermedio che usa EJB, con un back-end supportato da un RDBMS Sybase. MDA può generare software per i vari livelli più del codice "colla" per legarli assieme.

La visione di OMG comprende anche il Meta Object Facility (MOF) come parte centrale di MDA. Poiché il PIM e il PSM sono scritti in UML, che è anche lui un linguaggo di tipo MOF, dovrebbe essere possibile definire trasformazioni scritte in un linguaggio MOF. Attualmente OMG sta lavorando sulle specifiche QVT (Query, Views, Transformations) per supportare questa idea. In altre parole, QVT permette di standardizzare le trasformazioni fra PIM PSM e codice fra i vari fornitori.

 

Due tipi di MDA
I vari fornitori di tool che supportano MDA stanno aggiornando e riposizionando i loro prodotti nel contesto della terminologia MDA. Questo ha però prodotto due differenti versioni della visione MDA.

Il primo tipo, definito "elaborazionista", aderisce fedelmente alle linee guida OMG. Esistono quindi PIM, PSM e codice, tutti separati tra loro, con il PSM annotato con qualche sintassi. Viene automaticamente generato in genere il 50% e l'80% del codice, mentre il comportamento viene in genere specificato in un linguaggio di terza generazione. I fornitori di questa categoria includono Compuware OptimaLJ e io-Software ArcStyler.

Il secondo tipo, definito "translazionista", dice che il sistema deve essere interamente specificato all'interno del PIM. Questo approccio è chiamato anche "executable UML" e si basa sul lavoro di Shlaer-Mellor. Il PSM e il codice vengono generati automaticamente al 100% a partire dal PIM. In pratica quindi il PSM può essere sostanzialmente ignorato. Il comportamento è specificato utilizzando un linguaggio di specifica della semantica compatibile con "Precise Action Semantics". I fornitori di questa categoria includono Kennedy Carter e Bridgepoint

 

Quali sono i vantaggi di MDA?
MDA vuole raggiungere degli obiettivi degni di lode. La maggior parte di noi è sicuramente d'accordo con l'idea fondamentale di MDA che i requisiti business di un'applicazione sono più importanti di una particolare piattaforma tecnologica. Non ignoriamo anche il fatto che qualche volta la tecnologia può creare delle nuove necessità aziendali come nel caso del web, della telefonia di terza generazione o del wi-fi. Ma una volta che un requisito aziendale è stato specificato è possibile che in futuro venga implementato in una tecnologia differente da quella odierna. Come già detto, OMG suggerisce che un'applicazione sviluppata con MDA possa avere un ciclo di vita di 20 anni.

La possibilità per MDA di utilizzare UML PIM e PSM permette di ottenere una serie di vantaggi aggiuntivi a quello principale. Fra questi è da notare la possibilità di sviluppo e consegna rapidi, principalmente grazie all'uso di trasformazioni e di generazione automatica del codice. In base al tipo di MDA utilizzato i fornitori possono generare in automatico il 50%, l'80% o addirittura il 100% del codice utilizzando dei template che incapsulano design pattern, assicurando così una buona qualità del prodotto.

Un altro beneficio di MDA è che, per l'uso di UML alla base di PIM e PSM, da il giusto peso alla fase di modellazione e disegno.

Questa è la mia analisi dei vantaggi di MDA ovviamente; la vostra potrebbe essere diversa. Compuware per esempio dice che i vantaggi di MDA consistono in produttività, interoperabilità e qualità. Comunque, mi occorre qualcosa per strutturare il resto del mio articolo, per quello vi ho fornito la mia lista.

Ma ora permettetemi di chiedervi:

- i modelli sono importanti per voi?
- Le vostre piattaforme cambiano così di frequente?
- I vostri clienti lo comprerebbero?
- Non vi preoccupa l'idea che esistano due tipi di MDA?
- Il vostro processo di sviluppo può farvi fronte?
- Schiettamente: siete in grado di fare funzionare il tutto?

Poiché a seconda delle riposte che date si può determinare se MDA è utilizzabile o no nella vostra organizzazione permettetemi di analizzare i seguenti punti.

 

I modelli sono importanti?
Questa domanda può sembrare bizzarra: "certo che i modelli sono importanti!" dite voi. Si ma i vostri clienti si preoccupano anche loro dei modelli? La migliore analogia ai PIM e PSM che io conosca è quella dei Logical Data Models (LDM, conosciuti anche come diagrammi entità/relazione) e Physical Data Models (PDM). Se voi date importanza ai modelli sicuramente avrete numerosi LDM e PDM, tutti tenuti costantemente sincronizzati con strumenti come Embarcadero ErWin o Sybase PowerDesigner. Bene, voi avete i modelli ma ai vostri clienti interessano? Un LDM che descrive i dati posseduti da un'organizzazione è uno dei documenti tecnici di maggior valore che un'organizzazione può creare. L'informazione in un PIM deve come minimo includere l'informazione di un LDM, e questa informazione sarà quella più importante contenuta in un PIM. Se i vostri clienti non hanno mai avuto interesse in un LDM è poco probabile che avranno interessi in un PIM.

Guardiamolo da un altro punto di vista. Possiamo rendere i rappresentanti commerciali più interessati ai modelli se troviamo i giusti incentivi per loro. Quindi, sono premiati e incentivati i vostri dirigenti commerciali per vantaggi che sappiamo di ottenere solamente nel lungo termine? Perché un sistema costruito in tal modo costa di più se si considerano solamente i costi a breve termine. E se vi sono degli incentivi oggi, siete sicuri che rimarranno anche in futuro. Quando fra 10 anni apparirà una nuova piattaforma siete sicuri che verranno effettuati appropriati investimenti per creare una nuova serie di trasformazioni dal PIM al nuovo PSM? La vostra organizzazione manterrà sempre il passo?

Ma anche se avete incentivato i vostri dirigenti commerciali per capire e consolidare i PIM sviluppati per loro: i vostri affari sono stabili? State consegnando lo stesso insieme di caratteristiche di 20 anni fa? Una regola delle architetture a più livelli è quella che il meno stabile dipende dal più stabile. Se il modo con cui fate affari con la maggior parte dei vostri clienti è cambiato radicalmente, allora può darsi che i vostri affari si muovano più velocemente della piattaforma tecnologica che li supporta. Certamente varie organizzazioni da me conosciute usano cambi di tecnologia come un'opportunità per rivitalizzare gli affari che stanno rallentando. Se i cambiamenti commerciali sono rapidi come quelli tecnologici allora non c'è esigenza di essere indipendenti dalla tecnologia sottostante.

 

La vostra piattaforma è così instabile?
Tutti sappiamo che l'industria informatica è in perenne rinnovamento. Ma il punto non è ogni quanto sono definite nuove piattaforme ma invece quanto durano prima che il loro supporto cessi. In una riposta ad un mio precedente articolo (1), OMG ha asserito che esiste una "susseguenza di piattaforme middleware a vita corta.... che impediscono alle aziende di realizzare i guadagni a lungo termine ... derivanti dai loro investimenti in software e integrazione". Ma è il caso di far notare cosa significhi " a vita corta":

  • La piattaforma Java, che è considerata piuttosto nuova, esiste dal 1995. Al giorno d'oggi le JVM possono ancora eseguire codice scritto per il JDK 1.0.2 nove anni fa;
  • COM che è ancora al cuore delle applicazioni Office di Microsoft sta diventando vecchio di 20 anni;
  • Microsoft ha esteso (ancora una volta) il ciclo di vita della piattaforma Win16 e provvede altri 5 anni oltre all'annuncio di fine vita di un prodotto prima di annullare anche il supporto tecnico;
  • I protocolli TCP/IP sono vecchi di oltre 40 anni e occorrerà ancora un certo tempo prima che si passi a Internet2 basata sul protocollo IPv6 (che sarà comunque compatibile all'indietro);
  • Anche CORBA, che non è mai diventato lo standard di fatto per le piattaforme distribuite è comunque presente all'interno di EJB. Inoltre un CORBA Orb è presente in ogni desktop Java 1.4;
  • Effettivamente il sistema operativo VME di ICL sarà dismesso... nel 2012.

Ovviamente ho accuratamente scelto i miei esempi. Ci sono un altro sacco di piattaforme che sono state introdotte dai fornitori e poi dismesse poco dopo. Ma per i sistemi enterprise la predominanza di Java .Net e webservice significa che le piattaforme per gli anni a venire saranno molto stabili. Java è vecchio di 9 anni e in questo tempo è cresciuto e si è diffuso notevolmente. Nonostante che Sun possieda tale piattaforma è difficile pensare che IBM e Oracle permettano a Sun di perdere interesse in Java. E in ogni caso Java è più grande di Sun. Esistono diverse implementazioni open source di JVM (per esempio Blackdown), mentre il progetto Classpath di GNU è un'implementazione di tipo "clean room" delle API Java fino alla JDK1.4.

Microsoft nel frattempo sta cercando di rincorrere (e possibilmente di sorpassare) Java con .Net. Derivato chiaramente dall'architettura Java, rappresenta almeno 5 anni di sviluppo da parte di Microsoft. Come Sun è probabile che resti legata a Java per il futuro, è difficile immaginare che Microsoft non mantenga .Net per almeno vari decenni. Anche se volessero, gli occorrerebbero almeno altri 5 anni per crearne uno sostituto, e 5 anni per dismettere .Net. Nel frattempo il progetto Mono sta portando .Net su Linux, e la stessa Microsoft ha portato .Net su BSD. Se Microsoft abbandonasse .Net in futuro allora - come per la piattaforma Java - ci sarebbero un sacco di sviluppatori open source a mantenerla in vita.

In termini di rete queste piattaforme convergono tutte sui webservice. Tutti convergono su questo: Microsoft, Sun, IBM, Oracle, BEA e la lista prosegue. Con l'aggiunta di XML Schema, abbiamo pure uno standard neutrale per rappresentare il contenuto semantico. Non importa se iniziative come ebXML riusciranno a standardizzare le semantiche per collegare senza fatica B2B e B2C; il punto è che abbiamo già un metodo indipendente dalla piattaforma per far comunicare i sistemi fra di loro, quindi abbiamo già tutto quello che serve a MDA. Anche mentre i webservice continuano a maturare, alcuni fornitori come Borland stanno offrendo prodotti come Janeva che permettono l'interoperabilità fra i protocolli nativi di .Net e J2EE.

Quindi con Java e .Net abbiamo due piattaforme che esisteranno per ancora lungo tempo. La loro architettura a virtual machine estende ulteriormente la loro durata. E grazie ai webservice abbiamo un modo per farli interagire.

In ogni caso la crescente popolarità dell'open source fa calare il rischio della scelta di piattaforma. Se io scelgo di adottare un framework web proprietario per sviluppare la mia piattaforma web creo una dipendenza. Ma se io scelgo un framework open source (p.e.: Struts, WebWorks, Tapestry, Spring, Cocoon ecc.) allora io faccio la mia scelta basandomi sulla vitalità della comunità che sviluppa il framework, e al peggio posso supportare il framework da solo.

MDA non riduce il rischio piattaforma. Considerate questo frammento di codice di un'applicazione generata da Compuware OptimalJ:

//GEN-GUARD:REMOTEVIEW$pidfb3196086219373fb
package breakfast.application.ejb.breakfastorder;
...
import com.compuware.alturadev.application.*;
import com.compuware.log4j.LoggerCategory;

Queste dipendenze dalle librerie di OptimalJ significano che il codice generato deve essere eseguito in un qualche contenitore che provveda questi servizi. Per portare il PIM su un altro prodotto concorrente occorre almeno una definizione di questi servizi, lasciamo stare la difficoltà di esportare ed importare le informazioni nel PIM.

Considerate anche cosa significa modellare in un ambiente dove non esiste la piattaforma. Per esempio, come inviate un email? Il programmatore deve per prima cosa definire un'astrazione del servizio di spedizione mail, poi generare una serie di trasformazioni per realizzare questo servizio nel PSM e nel codice. Questo mi sembra il classico esempio di reinventare la ruota.

 

I vostri clienti lo compreranno?
Adottare MDA ha alcune implicazioni che i clienti devono comprendere. Questo assumendo che i clienti riescano a capire MDA abbastanza bene da adottarlo subito. Qualsiasi tecnologia che si basa su meta-meta-modelli è difficile da vendere, non importa quanti analisti ne abbiano scritto dei report favorevoli.

Ma i clienti dovrebbero realizzare che, nel ciclo di vita del progetto, usare MDA richiede che i clienti debbano fare degli investimenti iniziali per sostenere lo sviluppo e il debugging delle trasformazioni. Poiché il costo del progetto è principalmente all'inizio, questo aumenta le perdite se il progetto è in seguito cancellato.

Mentre ci state pensando, dovete anche accettare il fatto che adottare MDA (nella sua forma più completa) riduce drammaticamente il bisogno di programmatori Java, C# e VB. Invece la maggior parte diventano modellatori di applicazioni, mentre un piccolo numero diventano specialisti in trasformazioni (più o meno come si può incontrare al giorno d'oggi uno specialista in compilatori). Questo è un grande cambiamento di focus, che rappresenta un grosso impegno in investimenti di training.

 

Preoccupa avere due differenti tipi di MDA?
Come descritto nell'introduzione, i vari fornitori di tool che adottano MDA hanno riposizionato i loro tool nel contesto della terminologia MDA. Questo ha dato luogo ai tipi translazionista e elaborazionista.

Nell'approccio translazionista il comportamento è specificato utilizzando specifici diagrammi di stato assieme ad un'implementazione di Precise Action Semantics, cioè con un linguaggio semantico di azione. In effetti questa è un'estensione del metodo di Shlaer-Mellor. Mentre in translazionisti possono citare diversi successi, questi sono principalmente per sistemi realtime o embedded, utilizzanti linguaggio c++ generato in automatico. Inoltre la sintassi di ogni linguaggio semantico di azione è specifica per ogni fornitore. È possibile effettuare il porting fra i fornitori, ma questo rappresenta comunque una dipendenza su un particolare fornitore.

Nell'approccio elaborazionista il comportamento è aggiunto tipicamente come un raffinamento nel PSM oppure nel codice, il che significa che non c'è necessità di utilizzare un linguggio semantico. Dall'altra parte, siccome il PSM e il codice sono raffinati successivamente, sorge la necessità di mantenere le differenti rappresentazioni sincronizzate.

Esiste un alto grado di antipatia fra le due fazioni. I translazionisti non permettono elaborazioni del PSM o del codice generato "perché elaborare è stupido". Leon Starr scrive (2) : "L'elaborazione distrugge le specifiche originali. Infatti il processo di manipolazione delle specifiche con dettagli di implementazione di solito parte molto prima che le specifiche siano complete. Quindi il confine (fra i due) è sempre confuso."

Nello stesso tempo gli elaborazionisti criticano la limitata applicabilità dell'approccio translazionista. Warmer, Kleppe e Bast asseriscono (3): "(è) solamente utile nello ... sviluppo di software embedded". Asseriscono inoltre: "il linguaggio semantico non è ad alto livello ... (e) non ha una sintassi standard".

Come minimo questo significa che chi utilizza MDA non si deve aspettare che un PIM sviluppato con un tool di un tipo sia usabile con tool dell'altro tipo. E il fatto che esistano due tipi è come minimo sconcertante. Non dovrebbero esistere cose simili con un tool standard MDA.

 

Il vostro processo di sviluppo può farvi fronte?
Adottare MDA ha diverse grosse implicazioni anche sul processo di sviluppo. Qualsiasi tipo di MDA voi scegliate, dovrete fissare rigide procedure e processi per essere sicuri che i cambiamenti (caratteristiche/miglioramenti o correzioni bug) siano effettuati al posto giusto. Nell'approccio elaborazionista di MDA ci sono quattro posti dove un cambiamento può essere effettuato: nel PIM, nel PSM, nel codice o nelle trasformazioni. Nella visione translazionista ce ne sono due: nel PIM e nelle trasformazioni. E quando c'è una trasformazione che è stata modificata nasce anche il problema di gestione delle varie versioni. Una nuova versione di una trasformazione deve essere in grado di preservare un PSM o del codice originariamente creato da una versione precedente.

Se questi robusti processi e procedure mancano i cambiamenti saranno applicati nel posto sbagliato. In altre parole i manutentori incominceranno a modificare il codice generato in automatico. E ricordate: queste procedure devono rimanere buone per i prossimi 20 anni quindi devono essere profondamente integrate nella cultura ... un singolo entusiasta MDA in azienda non è abbastanza perché sopravvivano.

Adottare MDA richiede anche di avvicinarsi alle pratiche di sviluppo software di tipo "agile". Sebbene come altri io sia a favore dei processi agili, questi sono ancora sconosciuti da molte organizzazioni. Il bisogno di processi agili deriva dal fatto che MDA richiede ai modelli di essere trattati come software. Quelle organizzazioni che usano UML solamente come "blueprint" o schizzi (Flower (4)) scopriranno che MDA non gli permette di usare UML in quel modo.

 

Onestamente, funzionerà?
Ad un livello basso rimangono dei dubbi sostanziali. Uno dei più significativi è quello che è difficile esprimere il comportamento in UML. I diagrammi di interazione non sono utilizzabili per questo poiché mostrano solamente una singola interazione di un singolo scenario di istanze di oggetti. Il problema dei diagrammi di interazione è che si basano sull'istanza e non sul tipo.

Usare un approccio dichiarativo per definire il comportamento significa utilizzare OCL per specificare le pre e post condizioni per le classi. Sebbene OCL sia utilissimo per definire formalmente le semantiche delle interfacce pubbliche fra i componenti, è troppo oneroso per essere utilizzato per le interfacce private degli oggetti all'interno dei componenti. Aggiunge troppo rigore nei punti sbagliati del processo di sviluppo e quindi blocca l'agilità. Detto in questo modo: non riesco ad immaginarmi un programmatore Perl medio che molto gentilmente si offra di specificare il comportamento dei suoi programmi in questo modo. In ogni caso, l'approccio di trasformare OCL in un linguaggio specifico come Java è attualmente non sperimentato: i tool come Dresden-COL devono usare estensivamente la reflection generando così codice difficilmente correggibile.

I translazionisti risolvono il problema comportamentale utilizzando Precise Action Semantics. Comunque, come avevo già spiegato, in pratica questo significa legarsi al linguaggio di semantica di un particolare fornitore. Questo significa abbandonare investimenti in linguaggi come Java e .NET per favorire la sintassi proprietaria di un linguaggio semantico di un fornitore specifico. La piattaforma torna per vendicarsi.

Per gli elaborazionisti, il comportamento è aggiunto come un "raffinamento" (loro terminologia) al codice generato. In ArcStyler, si aggiunge il comportamento nel codice in posti indicati con i commenti: "aggiungi il tuo codice qui...". Ma qui non si tratta di raffinamento; si parla di andare al cuore dell'assegnamento delle responsabilità e quindi al cuore della modellazione. Ometterlo dal PIM significa che il PIM manca di informazioni significative. Tutto quello che questi tool fanno è quello di automatizzare la generazione del codice di base per le strutture statiche degli oggetti del dominio.

Un altro problema è costituito dall'immaturità dei tool, nonostante siano passati 3 anni dal lancio di MDA. I tool di supporto per capacità MOF generiche, come richiesto da un'interpretazione stretta dell'approccio elaborazionista, sono ancora imprecisi. Mentre svariati tool UML permettono di definire PIM e PSM, non sono comunque a conoscenza di MOF. Possono essere utilizzati per importare o esportare il formato MOF XMI perché capiscono lo spazio dei nomi UML, ma non possono essere utilizzati per modelli MOF arbitrari. Nessuno dei tool UML leader (Rational Rose, Borland Together e Embarcadero Describe) possiede un supporto generico MOF.

Perché la versione elaborazionista di MDA abbia successo, i fornitori non devono solamente far sì che i loro tool supportino MOF ma anche che supportino QVT (quando sarà definito). Sebbene io cerchi di non avere pregiudizi, questi sono gli stessi fornitori che non hanno mai implementato il precedente standard CWM di OMG nei loro tool, uno standard molto più semplice da implementare.

 

Tutto considerato
Ricapitoliamo gli obiettivi di MDA come li vedo io. L'obiettivo principale è quello di separare i requisiti del cliente e l'analisi dalla tecnologia. Un obiettivo secondario è quello di provvedere ad uno sviluppo rapido; un terzo è quello di enfatizzare la fase di modellazione.

Se ai vostri clienti non interessano i modelli e/o adottate una piattaforma Java o .Net utilizzando tecnologie open source e/o i vostri affari cambiano con la stessa rapidità delle tecnologie allora il primo obiettivo sembra discutibile.

Guardiamo al secondo punto: lo sviluppo rapido. Chiaramente la generazione automatica del codice produce benefici e miglioramenti di produttività. Comunque il costo iniziale della creazione dei modelli di trasformazione e dei generatori di codice sicuramente sarà preponderante rispetto a quello di scrivere solamente un'applicazione. I modelli di trasformazione forniti già pronti dai fornitori mitigano questo costo, ma se il cliente desidera un'applicazione molto specifica (e in genere è così, altrimenti avrebbero comprato un'applicazione generica di terze parti) allora i modelli pronti costituiscono solamente una base di partenza.

Il terzo obiettivo che ho elencato è l'enfasi sulla modellazione. Comunque questa enfasi è al più superficiale per gli elaborazionisti, principalmente per il problema che ho identificato di esprimere il comportamento degli oggetti e quindi delle loro responsabilità. Cioè se un designer non può fare facilmente esperimenti di assegnare differenti responsabilità agli oggetti allora è difficile per lui creare un design decente. Sommando tutto quello detto sopra non posso credere che MDA funzioni così come è stato definito da OMG. Ma non siamo così pessimisti, non è totalmente un fallimento:

  • Inanzitutto MDA sembra avere galvanizzato un interesse nella generazione automatica del codice. I tool come AndroMDA sono dei generatori di codice molto potenti e possono importare XMI come input. È molto distante dal risultato che voleva ottenere OMG, ma sicuramente non si può dire che non sia utile.
  • Sostanzialmente, l'utilizzo delle annotazioni di metadati in un PIM è molto simile ad un insieme di tecnologie che diventeranno molto importanti, in particolare i metadati di Java 1.5 accoppiati con la programmazione aspect-oriented (AOP). Quando AspectJ sarà migliorato per definire i pointcut basati sui meta-dati di Java 1.5, tutto questo sarà molto simile ai PSM.
  • Gli "aspect" potrebbero anche risolvere il problema comportamentale. OMG non voleva usare Java come sintassi per Precise Action Semantics perché come linguaggio non è abbastanza costretto. Permette di scrivere cose che non sono strettamente parte del PIM. Comunque, come si può definire un profilo UML che imponga una serie di vincoli ad un modello UML, così gli aspect possono definire un profilo di codice (supponiamo si possa chiamare così). Questi possono porre dei vincoli al comportamento del codice che si comporti in maniera da essere uno stretto sottoinsieme di quello che Java può fare. Si può notare una cosa simile nelle specifiche EJB dove il multi-threading e le chiamate Java-AWT non sono permesse.

MDA ha quindi contribuito alla definizione di un problema che AOP è nella posizione ideale per risolvere. Posso prevedere che in un anno o due si scriverà software dove si usa Java (o .Net) per scrivere gli oggetti di dominio e dove si usano le annotazioni e gli apects per rappresentare le caratteristiche del sistema. La prevalenza di framework open source che usano i POJO (plain old java object) è giusto l'inizio di questo trend.

E, essendo un avvocato dei Naked Object ( vedi (5) su The Server Side), posso prevedere una versione futura del "Naked Object Framework" che sia un vista sotto forma di "aspect" dei POJO. Quando avremo questo allora avremo veramente una tecnologia che enfatizza la fase di modellazione.

 

Unitevi ai dubbiosi
Spero di avervi generato almeno un po' di scetticismo riguardo al fatto che MDA possa funzionare così come descritto da OMG. Ma io non sono l'unico scettico. OMG si fanno forza del supporto di ditte del calibro di IBM, HP, Sun e Borland e annunciano allo stesso tempo che MDA è la fine della programmazione come la conosciamo ora. Ma questi fornitori stanno chiaramente differenziando le loro scommesse. Per esempio IBM ha effettuato ingenti investimenti in IDE tradizionali come Eclipse, senza contare gli investimenti nella programmazione ad aspetti. Inoltre, a marzo 2004 alla conferenza AOSD il CTO di IBM Daniel Sabbah ha asserito che: "AOP è vitale per la nostra sopravvivenza". È una frase molto chiara. E considerate i milioni di programmatori VB che la Sun sta seguendo con Project Rave: sicuramente non li sta convincendo a muoversi verso Java offrendo loro una soluzione MDA. E Microsoft? Si fa notare per la sua assenza.

Ma anche se sono scettico su MDA come descritto, penso che il problema, posto da OMG quando ha proposto MDA come soluzione, sia un problema che vale la pena venga risolto. E questo può essere il maggior contributo, provvedere la possibilità di usare nuove tecnologie come AOP. Ma la soluzione di OMG a questo problema è: non per me, grazie.

 

A proposito dell'autore
Dan Haywood ha lavorato su progetti software larghi e piccoli per 15 anni con Accenture e Sybase UK e per 6 anni come consulente indipendente, insegnante e scrittore tecnico. Dan è un esperto di Together Control Center in quanto ha collaborato a scrivere "Better Software Faster", un libero sull'uso e la personalizzazione di Together Control Center. Dan è anche un membro attivo della comunità dei "Naked Objects" e ha sviluppato un set di personalizzazioni per Naked Object e Together scaricabile dal suo sito, http://www.haywood-associates.co.uk/

L'articolo è stato originariamente pubblicato su TheServerSide.com