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
|