Concetto: MDD (Model-Driven Development) e MDA (Model Driven Architecture)
Questa guida introduce MDD e MDA il cui scopo principale consiste nell'enfatizzare il ruolo dei modelli nella progettazione del software.
Relazioni
Elementi correlati
Descrizione principale

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 Inizio pagina

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) Inizio pagina

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 Inizio pagina

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 Inizio pagina

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 Inizio pagina

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 icona della guida 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) Inizio pagina

Motivazione Inizio pagina

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 Inizio pagina

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 Inizio pagina

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 Inizio pagina

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) Inizio pagina

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 Inizio pagina

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) Inizio pagina

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 Inizio pagina

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 Inizio pagina

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 Inizio pagina

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 Inizio pagina

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 Inizio pagina

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, che mostra il modello PIM e altre informazioni come input per una trasformazione nonché il modello PSM e il record di trasformazione come output.

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 Inizio pagina

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 Inizio pagina

Lo scenario più semplice relativo all'applicazione di MDA è:

  1. Preparazione di un PIM
  2. Selezione di una piattaforma
  3. Preparazione di una mappatura, se non ne esiste già una
  4. Applicazione della trasformazione per produrre un PSM
  5. 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 Inizio pagina

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.

Tre applicazioni ripetute del pattern MDA per tre piattaforme diverse

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 Inizio pagina

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 Inizio pagina

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 Inizio pagina

Portabilità e interoperabilità Inizio pagina

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 Inizio pagina

Produttività Inizio pagina

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à Inizio pagina

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.