Introduzione
I modelli rappresentano un importante tipo di prodotto di lavoro nel Rational Unified Process e in RUP
vengono generalmente espressi mediante UML (Unified Modeling Language), un sistema indipendente dall'ambiente e dal
tool, in modo che RUP possa essere distribuito e attivato con diverse serie di tool in diversi ambienti. In Materiale di supporto: Modellazione visiva vengono esaminate alcune motivazioni
della modellazione, tra cui:
-
Comprendere sistemi complessi
-
Esaminare e confrontare alternative di progettazione a basso costo come base per l'implementazione
-
Acquisire i requisiti in maniera precisa
-
Comunicare le decisioni in modo chiaro
I modelli vengono concepiti come un modo per ragionare sulla struttura e sul comportamento (desiderato e realizzato)
del sistema e per comunicare i risultati di queste decisioni ai portatori d'interesse. MDD e MDA enfatizzano il ruolo
dei modelli come elementi fondamentali per l'implementazione, in attesa che diventino più di semplici progetti sulla
base dei quali gli Sviluppatori scriveranno il codice, ma sono a loro volta attivabili o eseguibili a un grado
proporzionato alla capacità della serie di tool di supporto. In questo modo viene seguita una tendenza, iniziata molto
tempo prima, di incremento del livello di astrazione a cui lavora lo Sviluppatore e l'attenzione viene spostata dal
codice come conosciuto ai modelli espressi in un linguaggio ancora più elevato, forse grafico. RUP supporta
implicitamente questa possibilità identificando determinati artefatti come modelli anziché documenti contenenti
immagini di modelli (ad esempio, mediante l'acquisizione di requisiti e progettazione).
Punti di vista e viste
Un punto di vista, come indica il termine, è una posizione nozionale da cui vengono resi visibili alcuni aspetti o
questioni relativi al sistema (o all'insieme di modelli che lo rappresentano), che implicano l'applicazione di una
serie di concetti e regole per formare un filtro concettuale. Il termine "prospettiva" viene utilizzato in modo
analogo, per descrivere un modo di visualizzare e comprendere i modelli che serve meglio i differenti orientamenti e
problematiche dei diversi portatori d'interesse.
Le viste sono proiezioni di modelli che mostrano entità rilevanti da uno specifico punto di vista o prospettiva.
In MDD i punti di vista e le viste vengono utilizzati, ad esempio, per separare le diverse problematiche per gestire la
struttura logica indipendentemente dalla struttura fisica e da quella del processo. Più i modelli sono vicini al
dominio del problema, maggiormente i punti di vista e le prospettive verranno associati alle problematiche aziendali
dei portatori d'interesse. Quanto più i modelli vengono sviluppati in modo simile alla forma eseguibile, tanto più
verranno intromesse le problematiche di calcolo. In entrambi i casi, lo scopo consiste non semplicemente nella
produzione di illustrazioni passive ma di modelli che siano, almeno potenzialmente, generativi di implementazioni che
soddisfano queste problematiche separate.
Elaborazione e conversione
(trasformazione)
Questi termini vengono utilizzati di frequente in modo informale per distinguere tra le modifiche del modello apportate
manualmente (elaborazione) e quelle apportate mediante un tool (conversione). In RUP l'elaborazione presenta un
significato formale alquanto diverso, rappresentando il nome di una fase del ciclo di vita, ma in questa sezione viene
utilizzata in modo informale per illustrare approcci apparentemente differenti all'evoluzione dei modelli.
La conversione e l'elaborazione presentano inoltre un significato di differente dimensione delle operazioni, per cui un
modello viene elaborato in una serie di piccole operazioni finché non vi siano sufficienti dettagli (tra cui quelli
relativi al linguaggio, all'infrastruttura o al sistema operativo) per generare codice dal suo interno, mediante un
tool o manualmente. Manualmente significa che un utente può esaminare il modello e scrivere Java, C++ o altri
linguaggi, eventualmente elaborando ulteriori elementi nel processo. Al contrario, nella conversione il modello, ancora
a un livello di astrazione non influenzato dalle problematiche relative al linguaggio, all'infrastruttura o al sistema
operativo, viene convertito in un elemento che esegue e produce il risultato desiderato con poca o nessun'altra
elaborazione. Si noti che il risultato desiderato include le prestazioni e altre caratteristiche non funzionali. Di
conseguenza, in questo approccio è implicito che tali problematiche strutturali di montaggio incrociato vengano
affrontate nel modo in cui è costruito il modello e in quello utilizzato per descrivere i requisiti delle risorse.
Un'altra parola, Definizione
del termine: trasformazione, è stata introdotta per descrivere il processo di generazione di un modello di
destinazione da un modello di origine seguendo un insieme di regole e operando in base a un insieme di parametri. Il
termine "modello" viene utilizzato qui nello stesso senso di RUP, in modo che il modello di destinazione possa far
riferimento agli elementi di implementazione, ad esempio codice o testo. Naturalmente la trasformazione può essere
effettuata manualmente, rendendo le successive trasformazioni (aggiunta di dettagli) equivalenti all'elaborazione, e le
regole possono essere molto complesse e basate sulla profonda esperienza della tecnologia disponibile e del dominio.
Tuttavia, per impostazione predefinita la trasformazione viene effettuata automaticamente, come verrà esaminato
nuovamente nella prossima sezione relativa a Model Driven Architecture®.
Il concetto di trasformazione implica semplicemente un modello di origine e uno di destinazione. Di solito il modello
di destinazione è meno astratto di quello di origine, ossia la destinazione è in qualche modo più specifica rispetto
all'origine, ma questo aspetto non è implicito nel concetto di trasformazione. La trasformazione può anche aggiungere
dettagli a un modello, producendo un modello di destinazione maggiormente perfezionato, rimanendo al contempo allo
stesso livello di astrazione nel senso che non vengono introdotte informazioni rilevanti per un altro dominio. Al
contrario di una trasformazione che produce codice da un modello UML, la maggior parte degli elementi introdotti in
questo modello di destinazione non crea alcun problema al portatore d'interesse aziendale, a condizione che vengano
mantenuti il comportamento richiesto e le caratteristiche non funzionali.
La possibilità di realizzare una conversione ottimale dipende dalle funzionalità del tool e dalla capacità dell'utente
di codificare, acquisire e riutilizzare le conoscenze impiegate da un esperto. La quantità di conoscenze che devono
essere acquisite e codificate dipende dal livello di astrazione a partire dal quale si effettua l'operazione di
conversione: più alto è il livello, maggiore sarà in genere la dipendenza del dominio e delle conoscenze.
In MDD, viene aumentato il livello di astrazione a partire da cui è possibile generare automaticamente un sistema
operativo. Un modello viene elaborato al punto in cui è possibile utilizzarlo per generare elementi. L'opzione
preferita, quindi, è che l'output non debba essere ulteriormente elaborato per poter essere eseguito. In pratica, il
nostro reale obiettivo consiste nel fare in modo che la precedente elaborazione resti valida, per quanto possibile,
anche nelle successive fasi di trasformazione automatizzate. I due approcci, pertanto, convergono: la conversione viene
realizzata mediante successive operazioni di trasformazione, automatizzate per quanto possibile. La trasformazione
finale al sistema di esecuzione si verifica con la descrizione del modello ancora a un alto livello di astrazione e con
le opzioni di scelta relative a tecnologia, infrastruttura e linguaggio di destinazione codificate nel motore di
trasformazione e nelle regole e i dati forniti ad esso.
Un altro vantaggio di MDD consiste nella possibilità di riutilizzare le trasformazioni nella codifica della piattaforma
nonché della conoscenza del dominio e delle procedure ottimali attraverso la creazione da parte di esperti nei domini
corrispondenti. In questo modo, viene semplificato il riutilizzo da parte di Sviluppatori meno esperti e viene evitata
un'altra creazione daccapo con ogni nuova applicazione.
Definizione di alto livello di astrazione
Esistono alcuni modi per prendere in esame questo concetto. Uno è con lo spettro di linguaggio e qui, ad esempio, viene
esaminata la manifestazione delle forme di un UML eseguibile. Un altro è dalla prospettiva della progettazione del
dominio, in cui possono essere specificate le problematiche relative alla modellazione e al linguaggio. Ad esempio, UML
è un linguaggio a scopo generico, pertanto con questa dimensione è possibile trovare l'utilizzo di Definizione del termine: profilo UML per specificare l'utilizzo di UML. Un altro
modo ancora è dato dalla necessità avvertita di evitare modelli specifici dell'infrastruttura o del fornitore così da
restare aperti alla nuova tecnologia.
In termini di espressione delle dinamiche dettagliate, il lavoro effettuato sulle Semantiche di azione UML ha reso
possibili forme eseguibili di UML, ma la notazione e la sintassi concrete non sono standardizzate e il livello delle
semantiche di azione è simile ad altri linguaggi OO. Di conseguenza, UML più le semantiche di azione probabilmente non
rappresentano la risposta finale, ma solo un'indicazione della direzione seguita.
In conclusione un modello espresso in UML, o che utilizza un profilo UML, che non contiene elementi dipendenti dal
fornitore, non è dipendente da una particolare piattaforma di infrastrutture, quale J2EE o Microsoft® .NET, ed è
completo semanticamente nella struttura e nel comportamento senza ricorso a un determinato linguaggio procedurale
(Java, C# e così via), è a un alto livello di astrazione in base a questa definizione, anche se resta il problema del
livello delle semantiche di azione.
Da una prospettiva di dominio del problema, ossia dal punto di vista del cliente aziendale o dell'utente, una soluzione
possibile e allettante è data dalla formulazione di linguaggi di modellazione specifici del dominio. Si tratta dei
linguaggi astratti, nel senso che vengono espressi in termini e concetti familiari ai lavoratori presenti nel
particolare dominio ma dispongono di capacità completa di esprimere le dinamiche dei modelli e sono sempre basati su
UML.
Relazione con RUP
La relazione dei modelli di analisi, progettazione e implementazione RUP illustra questi concetti: il Modello di analisi rappresenta una vista precedente del modo in cui
verrà realizzato il comportamento espresso nei casi d'uso. È ovviamente deviato descrittivamente verso il dominio del
problema risolto e le Classi di analisi contenute in esso vengono considerate come
raggruppamenti concettuali del comportamento e delle responsabilità richieste. Il modello di analisi in genere non è
sufficientemente completo per poter essere eseguito, tranne forse in un esperimento teorico da parte di una persona che
legga il modello e colmi le lacune, poiché vi sono troppi concetti inespressi. Al contrario, tale modello deve passare
attraverso un processo di perfezionamento, aggiunta di dettagli e precisione per determinare il Modello di progettazione.
RUP consente a un progetto di mantenere un modello di analisi separato o di considerare tale modello come un elemento
destinato a evolversi nel modello di progettazione. Il processo di perfezionamento viene descritto a un certo punto dei
compiti di RUP, con l'interpretazione predefinita secondo cui chi svolge i ruoli di Architetto e Progettista software
completerà questa evoluzione, probabilmente con un considerevole supporto di tool. Tale perfezionamento può essere
considerato come una sequenza di trasformazioni del modello, alcune delle quali potrebbero essere automatizzate, ad
esempio, nell'applicazione dei pattern Definizione del termine: pattern di analisi e Definizione
del termine: pattern di progettazione nei compiti di RUP Analisi
strutturale e Identificazione dei meccanismi di progettazione .
Momento in cui il modello di
progettazione è completo
Il modello di progettazione evolve per tutta la durata del progetto attraverso diverse iterazioni. Di conseguenza,
quando tale modello o alcune sue parti possono essere trasformati in codice, ovvero quando è possibile iniziare a
produrre Elementi di implementazione e integrarli nei Build di rilievo del sistema? RUP offre una guida sulla Mappatura dalla progettazione al codice ma sostanzialmente non esistono risposte
concrete e rapide. L'utente passa all'implementazione quando, attraverso un'analisi ad esempio, ritiene che sia
possibile e tale punto può variare considerevolmente tra le organizzazioni e i progetti. RUP offre una serie di metodi
per procedere dalla progettazione al codice, due dei quali vengono trattati qui per illustrare il modo in cui vengono
prese le decisioni sulla completezza della progettazione:
1. Bozza e codice
Secondo RUP, un approccio comune alla progettazione consiste nel delinearla a un livello piuttosto astratto e quindi
passare direttamente al codice. La gestione del modello di progettazione è manuale.
Per essere in linea con questo approccio, è necessario che lo Sviluppatore sia in grado di colmare il divario di
astrazione tra i livelli di progettazione e di implementazione. Di frequente, pertanto, la gestione del modello di
progettazione rappresenta un aspetto secondario, mentre il codice diventa il punto centrale.
2. RTE (Round-Trip Engineering) con il modello di progettazione singolo in evoluzione
Secondo RUP, in questo approccio è presente un modello di progettazione singolo. Le bozze iniziali degli elementi di
progettazione vengono elaborate fino al punto in cui possono essere sincronizzate con il codice.
Qui gli Sviluppatori colmano il divario di astrazione con una sequenza di operazioni di modellazione. La differenza tra
questo approccio e "bozza e codice" è data dal fatto che le operazioni intermedie sono manifeste e, al termine, la
versione astratta del modello di progettazione scompare.
In entrambi i casi, il valore potenziale di un modello di progettazione astratto viene perso: in "bozza e codice"
poiché il modello di progettazione astratto in genere non viene mantenuto e, con il passare del tempo, perde contatto
con il codice e nel "modello di progettazione singolo in evoluzione" poiché la versione astratta scompare. Anche se
viene conservata una versione iniziale, in genere ha lo stesso destino del modello di progettazione in "bozza e
codice". Il punto finale del modello di progettazione con RTE è effettivamente la visualizzazione del codice e una
simile visualizzazione potrebbe essere sottoposta a reverse-engineering dal codice prodotto in "bozza e codice" con i
tool appropriati. In RUP la perdita del modello di progettazione astratto viene mitigata, fino a un certo punto,
acquisendo significative viste strutturali e presupposti logici della progettazione nei punti critici all'interno del
documento dell'architettura software.
MDD offre la possibilità che il modello di progettazione astratto diventi fondamentale per la generazione di codice e
duraturo. Diventa la base principale per la gestione e, in effetti, può essere la sola base per quest'ultima. Offre
inoltre una chiara definizione del punto finale della progettazione, ossia del punto in corrispondenza del quale, per
quel che riguarda il motore di trasformazione, il modello è completo, coerente e non ambiguo e in grado di essere
trasformato in un sistema eseguibile. Il livello di astrazione del modello dipende dalla tecnologia e dalla serie di
tool disponibili (per un esempio, vedere Presentazione del tool: panoramica su Rational Software
Architect) e potrebbe anche essere dipendente dal dominio. Per quanto riguarda MDD, si tratta semplicemente di un'altra
trasformazione (da progettazione a codice) ma importante che oltrepassa i livelli di astrazione.
Nella sezione successiva viene descritto uno standard di framework emergente per MDD, un'iniziativa dell'OMG (Object
Management Group) denominata MDA® (Model Driven Architecture®).
MDA (Model Driven Architecture)
Motivazione
MDA è un'iniziativa dell'OMG, un consorzio industriale di circa 800 membri con l'obiettivo di stabilire specifiche e
linee guida standard per fornire un framework comune indipendente dal fornitore per lo sviluppo delle applicazioni e
incoraggiare l'interoperabilità nelle principali piattaforme di infrastrutture hardware e software. Unified Modeling
Language è un prodotto dell'OMG. L'OMG ora promuove MDA come specifica principale e con la posizione di OMG di
promulgatore di standard pratici destinati a essere supportati da IC, procedure, prodotti e tool del settore e
considerato il successo di UML, MDA merita tutta l'attenzione che gli viene data. Esistono numerose informazioni su
MDA, inclusa la più recente Guida MDA [OMG03], sul sito Web di OMG.
Esistono inoltre diversi manuali disponibili quali [FRA03], [KLE03] e [MEL04] nonché diversi articoli, quali "An MDA Manifesto" di Grady Booch, Alan Brown,
Sridhar Iyengar, James Rumbaugh e Bran Selic in The MDA Journal, maggio 2004.
Concetti principali di MDA
MDA introduce determinati concetti e terminologia specifici, definiti e trattati nelle sezioni riportate di seguito,
che lo distinguono dagli approcci più generali a MDD.
Creazione sulla base degli
standard esistenti
MDA si basa sugli standard OMG esistenti, tra cui:
-
Infrastruttura dei metaoggetti (MOF, Meta-Object Facility): oltre a definire un linguaggio per la creazione di
metamodelli, ad esempio UML e CWM, MOF definisce un framework per l'implementazione di
repository relativi a modelli e metamodelli, consentendo un approccio coerente alla modifica di tali modelli
durante l'utilizzo di MDA. MOF rappresenta, pertanto, una tecnologia essenziale per MDA.
-
UML (Unified Modeling Language): PIM, PM e
PSM vengono definiti in UML, che rappresenta la notazione fondamentale di
MDA.
-
XMI (XML Metadata Interchange): XMI definisce un formato di scambio di modelli UML basato su XML.
-
CWM (Common Warehouse Metamodel): mentre UML viene
utilizzato per la modellazione delle applicazioni, CWM viene utilizzato per la modellazione dei dati.
Indipendenza dalla
piattaforma
Una nozione intuitiva di Definizione del
termine: piattaforma è quella secondo cui una piattaforma supporta un livello strutturale più elevato attraverso la
fornitura di servizi con un insieme ben definito di interfacce che nascondono i dettagli di implementazione. La
definizione di piattaforma dell'OMG (nella Guida MDA) è:
"Insieme di sottosistemi/tecnologie che fornisce una serie coerente di funzionalità tramite interfacce e pattern di
utilizzo specificati che qualsiasi sottosistema, che dipende dalla piattaforma, può utilizzare senza preoccupazioni per
i dettagli su come viene implementata la funzionalità fornita dalla piattaforma".
Si tratta di un concetto simile a quello di Definizione del
termine: livello utilizzato in RUP.
Il concetto di indipendenza dalla piattaforma è leggermente sfuggente: si tratta di una qualità o
caratteristica di un modello, ad esempio si potrebbe dire che un modello è indipendente da una determinata piattaforma
quando non contiene riferimenti a servizi o funzionalità forniti da tale piattaforma. Tuttavia, tale affermazione è
relativa poiché è difficile immaginare una forma assoluta di indipendenza dalla piattaforma. La Guida MDA tiene conto
di questa difficoltà e prevede anche diversi gradi di indipendenza dalla piattaforma rispetto a una determinata
piattaforma in cui, ad esempio, un modello utilizzi una forma generalizzata di funzione di una determinata piattaforma.
Il raggiungimento dell'indipendenza dalla piattaforma è stato favorito dall'evoluzione di piattaforme quali J2EE, .NET
e WebSphere verso livelli di astrazione maggiori in termini di elementi esposti alle applicazioni. In questo modo viene
resa molto più agevole l'identificazione dei costrutti indipendenti dalla piattaforma e risultano molto più semplici e
facili da scrivere le trasformazioni specifiche della piattaforma che ne effettuano la conversione.
Modello indipendente dalla piattaforma (PIM,
Platform Independent Model)
Ne consegue che è possibile affermare che un modello è un PIM rispetto a una determinata piattaforma quando non è
collegato all'utilizzo di tale piattaforma e può essere utilizzato con qualsiasi piattaforma di quel tipo. In una
sezione precedente è stato illustrato il concetto di alto livello di astrazione e si è arrivati alla conclusione che un
modello espresso in UML (o che utilizza un profilo UML) che non contiene elementi dipendenti dal fornitore, non è
dipendente da una particolare piattaforma di infrastrutture ed è semanticamente completo nella struttura e nel
comportamento senza ricorso a un determinato linguaggio procedurale, è almeno a livello nozionistico eseguibile e a un
alto livello di astrazione. È possibile affermare che un modello di questo tipo sia indipendente dalla piattaforma? Sì
e no. No, rispetto a una macchina virtuale UML immaginaria e sì, rispetto all'intera classe di piattaforme da cui
dipenderebbe tale macchina virtuale.
Modello di piattaforma
Il modello di piattaforma è l'insieme di concetti (che rappresentano parti e servizi), specifiche, definizioni di
interfacce, definizioni di vincoli ed eventuali altri requisiti di cui necessita un'applicazione per utilizzare una
determinata piattaforma. In MDA i modelli di piattaforma sono dettagliati e formalizzati, ad esempio in UML, e sono
disponibili in un repository compatibile con MOF. Ad esempio, i modelli di piattaforma possono essere costruiti, fra
gli altri, per J2EE o .NET.
Modello specifico della piattaforma
(PSM, Platform Specific Model)
Un modello PIM viene trasformato in uno o più PSM mediante l'aggiunta di informazioni che lo rendono specifico a una
determinata piattaforma o piattaforme. I modelli PIM e PSM specificano lo stesso sistema, ma PSM è vincolato a una
determinata tecnologia e può contenere elementi specifici della piattaforma. Non esiste alcuna implicazione derivante
dal fatto che un'operazione di trasformazione (da PIM a PSM o alla relativa piattaforma associata) sia di grande o
piccola portata. Un'operazione di trasformazione che interessa l'applicazione di un piccolo gruppo di pattern
perfeziona il modello e, in un certo senso, lo rende più specifico. Questa considerazione evidenzia la relatività dei
termini PIM e PSM.
Punti di vista e Vista
Questi termini vengono utilizzati in MDA nello stesso modo descritto per MDD:
-
Un punto di vista, come indica il termine, è una posizione nozionale da cui vengono resi visibili alcuni aspetti o
questioni relativi al sistema, che implicano l'applicazione di una serie di concetti e regole per formare un filtro
concettuale. Dato che alcune informazioni sul sistema sono state soppresse, si tratta di una forma di astrazione.
Il termine prospettiva viene utilizzato in modo analogo.
-
Da un punto di vista è possibile visualizzare viste, che rappresentano proiezioni di modelli che mostrano
entità rilevanti da tale punto di vista.
MDA specifica tre punti di vista in un sistema: un punto di vista indipendente di calcolo, uno indipendente dalla
piattaforma e un altro specifico della piattaforma.
Punto di vista
indipendente di calcolo
Dal punto di vista indipendente di calcolo, viene considerato il contesto relativo al sistema, i requisiti e i vincoli
sotto cui deve operare nonché gli elementi presenti nell'ambiente con cui deve interagire. Da questo punto di vista non
vengono visualizzati i dettagli della struttura o del comportamento del sistema.
Il modello indipendente di calcolo (CIM, Computation Independent Model) è una vista del
sistema o di come deve essere dal punto di vista indipendente di calcolo. Il CIM è simile concettualmente a una
combinazione del modello di dominio in RUP, che rappresenta l'insieme degli artefatti, tra cui glossario di business e
modello di analisi del business, prodotti dal Compito: sviluppo di un modello di dominio (nella modellazione del
business) con il modello del caso d'uso, che rappresenta invece la descrizione del comportamento del sistema
indipendente a livello di calcolo. Il CIM, espresso nel linguaggio degli esperti del dominio o dell'argomento, è un
importante collegamento nell'identificazione, durante l'analisi e la progettazione, delle astrazioni chiave all'interno
del sistema così come deve essere.
Punto di vista indipendente
dalla piattaforma
Il punto di vista indipendente dalla piattaforma è relativo a una determinata piattaforma. Da tale punto di vista è
possibile visualizzare la struttura e il comportamento di un sistema senza i dettagli di tale piattaforma. Il PIM
rappresenta una vista del sistema dal punto di vista indipendente dalla piattaforma.
Punto di vista specifico della
piattaforma
Dal punto di vista specifico della piattaforma, pure relativo a una determinata piattaforma, è possibile visualizzare
gli elementi prima visibili dal punto di vista indipendente dalla piattaforma insieme ai dettagli di utilizzo della
piattaforma, ora resi disponibili. Il PSM è una vista del sistema da un punto di vista specifico della piattaforma.
Automazione della trasformazione
Il concetto di trasformazione è fondamentale per MDA e la trasformazione dei modelli viene definita semplicemente come
"il processo di conversione di un modello in un altro dello stesso sistema". MDA definisce inoltre un piccolo
pattern per visualizzare la conversione e per illustrare l'utilizzo di parte della terminologia esaminata:
Pattern MDA
Lo scopo del diagramma consiste nel mostrare che la trasformazione è un elemento di prima classe: la trasformazione,
infatti, raccoglie il PIM e altre informazioni e le combina in modo da produrre il PSM.
La trasformazione dei modelli può, ovviamente, essere effettuata manualmente. Si tratta di un metodo leggermente
differente rispetto a quello in cui è sempre stata sviluppata la progettazione software. Anche in questo caso, MDA è
utile per delineare e formalizzare il concetto di trasformazione, il processo e le altre informazioni da utilizzare.
MDA suggerisce inoltre di creare un record della trasformazione: questa operazione fornisce una forte tracciabilità dal
PIM al PSM in quanto deve includere una mappa degli elementi del PIM fino a quelli del PSM. La maggior parte dei
vantaggi deriva dalla possibilità di automatizzare le trasformazioni, anche se solo parzialmente, producendo gli stessi
vantaggi che derivano dalla sostituzione della programmazione di assemblaggio con linguaggi di alto livello.
Modalità di esecuzione di una
trasformazione
MDA non prescrive un unico modo per effettuare una trasformazione: viene preparata una mappatura, basata sulla scelta
di una piattaforma, per specificare il modo in cui trasformare un PIM in un PSM per tale piattaforma. Questa mappatura
determina una definizione della trasformazione (forse espressa come insieme delle regole di trasformazione),
possibilmente con parametri di trasformazione scritti in un linguaggio di definizione della trasformazione. L'OMG ha
emesso una RFP (MOF 2.0 Query/Views/Transformations RFP) in attesa della standardizzazione (relativa a MOF) dei
linguaggi per creare viste dei modelli, eseguire query in un modello e scrivere definizioni della trasformazione. La
Guida MDA descrive diversi approcci alla trasformazione, tra cui:
-
Trasformazione di metamodelli: questo approccio presuppone l'esistenza di un metamodello MOF a livello di PIM nel
linguaggio su cui è basato il PIM. Allo stesso modo, per la piattaforma scelta, esiste un metamodello a livello di
PSM nel linguaggio in cui può essere creato un PSM. È possibile utilizzare una mappatura tra i due metamodelli per
creare una definizione della trasformazione, che verrà utilizzata per trasformare un PIM in un PSM.
-
Applicazione di contrassegni: viene preparata una mappatura relativa alla piattaforma scelta. Questa mappatura
viene utilizzata per creare una definizione della trasformazione che includa un insieme di contrassegni da
applicare agli elementi del PIM, generando un "PIM contrassegnato", e una definizione delle operazioni da eseguire
con gli elementi contrassegnati in questo modo. Il PIM contrassegnato viene quindi ulteriormente trasformato per
produrre il PSM. L'applicazione di contrassegni è di solito un processo manuale, ma la successiva trasformazione
può essere automatizzata.
-
Trasformazione di modelli: il PIM viene creato mediante tipi indipendenti dalla piattaforma, specificati anche in
un modello, in cui gli elementi del PIM sono sottotipi dei tipi in questione. Viene scelta una determinata
piattaforma, associata a un insieme di tipi specifici della piattaforma. Viene effettuata una mappatura tra i due
insiemi di tipi, che genera una definizione della trasformazione che verrà applicata al PIM, producendo un PSM
espresso nei sottotipi dei tipi specifici della piattaforma. Questo approccio è per alcuni versi simile alla
trasformazione di metamodelli, eccetto che per il fatto che la trasformazione viene ristretta ai tipi presenti in
un modello piuttosto che ai concetti di un metamodello MOF.
-
Applicazione di pattern: il PIM viene creato mediante un insieme di tipi e pattern astratti indipendenti dalla
piattaforma. Per la piattaforma scelta esiste un insieme di tipi e pattern specifici della piattaforma. Viene
effettuata una mappatura tra i due insiemi di tipi e pattern, che offre una definizione della trasformazione da
applicare al PIM. In questo modo viene prodotto un PSM in cui i pattern astratti sono stati generati come specifici
della piattaforma.
Per ulteriori dettagli, si rinvia alla Guida MDA [OMG03].
Modalità di applicazione di una trasformazione
Lo scenario più semplice relativo all'applicazione di MDA è:
-
Preparazione di un PIM
-
Selezione di una piattaforma
-
Preparazione di una mappatura, se non ne esiste già una
-
Applicazione della trasformazione per produrre un PSM
-
Trasformazione del PSM in codice. Se il PSM non necessita di ulteriore perfezionamento e può essere implementato
direttamente, costituirà un'implementazione come definito nella prossima sezione
I PSM per le altre piattaforme possono essere generati nello stesso modo.
Applicazione ripetuta del pattern MDA
Il pattern MDA è anche suscettibile di applicazione ripetuta: un PSM generato in un livello diventa il PIM per il
successivo, ossia per la successiva scelta della piattaforma sempre più specifica. Si noti che in MDD, in quanto
descritto in RUP e supportato con la serie di tool di IBM Rational, la scelta preferita consiste nel ridurre al minimo
il numero di operazioni di perfezionamento, ovvero procedere da una rappresentazione vicina all'esposizione del
problema del cliente a una forma eseguibile il più direttamente possibile.
Applicazione ripetuta del pattern MDA
Lo scopo del diagramma precedente è mostrare tre applicazioni del pattern MDA, con il PIM iniziale che diventa un PSM
dipendente dalla piattaforma 1, quindi trasformato di nuovo in modo da essere dipendente anche dalla piattaforma 2 e
infine trasformato ancora in modo da essere dipendente dalle piattaforme 1, 2 e 3.
Trasformazione generale da un modello a un altro
Gli stessi concetti possono essere applicati a una trasformazione generale, ossia da un modello qualsiasi a un altro.
Se, ad esempio, esistono due metamodelli i cui linguaggi vengono utilizzati per esprimere i modelli, in linea di
principio potrà essere effettuata una mappatura che generi una definizione della trasformazione. La relativa
applicazione verrà effettuata nello stesso modo visto per la trasformazione da PIM a PSM.
Implementazione
La Guida MDA utilizza il concetto di "implementazione" in modo simile a quello del modello di implementazione di RUP.
Si tratta di una specificazione di tutti gli Elementi di implementazione necessari per creare, distribuire,
installare e mettere in funzionamento il sistema.
Un PSM può essere a sua volta un'implementazione o può richiedere un ulteriore perfezionamento prima di poter essere
trasformato in codice. La produzione di un PSM di implementazione può ignorare l'operazione di manifestazione del PSM e
passare direttamente al codice. In questo caso, il PIM più astratto può essere trasformato direttamente in codice
mediante il motore di trasformazione. È sempre possibile fornire una visualizzazione del codice allo Sviluppatore per
agevolarne la comprensione, ma questa può essere sottoposta a reverse engineering da parte del codice.
Possibili vantaggi
Portabilità e
interoperabilità
MDA offre la possibilità di controllare le spese e la perturbazione del continuo progresso tecnologico, consentendo la
ridestinazione di un insieme relativamente stabile di PIM a qualsiasi nuova tecnologia venga richiesta. La previsione è
che, con la sempre maggiore accettazione di MDA, gli Sviluppatori di nuova tecnologia offriranno anche le mappature in
modo da rendere rapide le successive trasformazioni.
Estendendo le mappature PIM-PSM relative a due piattaforme, MDA suggerisce di creare "ponti" tra i due PSM e in
definitiva tra le due implementazioni, in modo da poter distribuire un PIM nelle piattaforme. La maggior parte delle
aziende si trova a dover affrontare la realtà dello sviluppo per ambienti eterogenei con un misto di nuove e vecchie
tecnologie, pertanto questa possibilità di realizzare l'interoperabilità potrebbe essere di grande utilità.
Riduzione dei costi del ciclo di vita
Produttività
Il punto centrale dello sviluppo con MDA diventa il PIM più astratto. Con un'efficace serie di tool per generare un PSM
(o codice), un tale ambiente dovrebbe essere più produttivo nello stesso modo in cui operare in un linguaggio di alto
livello è più produttivo che operare in un assemblatore, specialmente dato che un PIM, o un elemento simile, è spesso
sviluppato in ogni caso, ad esempio fungendo da modello di progettazione in RUP. Il vantaggio in termini di
produttività dipende in modo critico dall'entità dell'intervento manuale necessario nel processo di trasformazione.
Qualità
Idealmente in MDA la destinazione della gestione è il PIM. Di conseguenza, a condizione che il PIM sia ben strutturato,
dovrebbe esistere un numero minore di difetti nella vita del prodotto poiché esistono minori opportunità per una
persona di introdurli e la correzione dei difetti riscontrati dovrebbe essere meno dispendiosa, grazie al vantaggio
della trasformazione automatizzata. La concentrazione sul PIM è inoltre più strettamente in linea con le problematiche
relative al dominio, pertanto la probabilità di soddisfare le esigenze degli utenti dovrebbe essere maggiore.
|