Conceitos: MDD (Model-Driven Development )
e MDA® ( Model Driven Architecture®)
Tópicos
Introdução
O RUP caracteriza muitos de seus artefatos como modelos
, que ele define como abstrações ou descrições de sistemas de perspectivas específicas;
a construção de modelos - em modelos visuais específicos
- também é realçada como uma boa prática no RUP (consulte
Boa
Prática: Modelar Visualmente (UML)
). No entanto, embora o RUP identifique muitos modelos e descreva como, como entradas
e saídas, mediam entre atividades, não prescreve a forma precisa dos modelos
(exceto de forma notacional) nem requer uma maneira específica de transformar
um modelo em outro. Assim, é possível instanciar e implementar o RUP para o desenvolvimento
de software de modo que, enquanto os modelos são produzidos, eles servem somente como mecanismos
de descoberta, documentação e comunicação e afetam o código desenvolvido somente por meio
de intermediários do desenvolvedor humano.
O MDD (Model-Driven Development) aumenta o nível de abstração, embora exija rigor
nas descrições do modelo e modelos de visualização não simplesmente como artefatos de
desenvolvimento intermediário, mas como descrições precisas a partir das quais os sistemas
operacionais podem ser gerados. O MDD obviamente conta com ferramentas mais avançadas para obter êxito
com um espectro de possíveis recursos, desde a produção de gabaritos até a geração de um código
completo.
A MDA® (Model Driven Architecture® é um OMG (Object Management Group)
iniciativo para descrever uma estrutura completa para a ativação da MDD. Ela apresenta
terminologia e idéias específicas ao confiar no trabalho de padronização anterior,
como a Unified Modeling Language e a Meta Object Facility, para configurar uma abordagem
transformacional rigorosa para o desenvolvimento do software e uma base para a automação
por meio de ferramentas.
MDD (Model-Driven
Development)
Modelos e Modelagem 
Os modelos são um tipo importante de artefato no Rational Unified Process e são
normalmente expressos (no RUP) utilizando a UML (Unified Modeling Language),
em uma ferramenta e um modo de ambiente neutro, assim o RUP pode ser implementado e ativado
com muitos conjuntos de ferramentas em muitos ambientes. A Boa Prática do RUP: A opção Modelar Visualmente
explora alguns dos motivos para modelagem, por exemplo:
- Ajudar na compreensão de sistemas complexos
- Explorar e comparar alternativas de design a um baixo custo
- Como uma fundação para implementação
- Capturar requisitos com precisão
- Comunicar decisões sem ambigüidade
Os modelos são vistos como uma maneira de refletir sobre o comportamento do sistema (tanto o
desejado quanto o realizado) e a estrutura e comunicar os resultados dessas deliberações
para os investidores interessados. A MDD continua enfatizando a função dos modelos como elementos
fundadores para implementação, na expectativa de que eles serão mais do que projetos
com base em quais desenvolvedores humanos escreverão códigos, mas eles mesmos são
ativáveis ou executáveis em um grau que depende do recurso do conjunto de ferramentas
de suporte. Isso segue uma tendência, começada há muito tempo, de aumentar o nível de
abstração em que o desenvolvedor humano trabalha. Isso desvia a atenção do código
como conhecemos para os modelos expressos em uma linguagem ainda mais alta, talvez gráfica.
O RUP, ao identificar determinados artefatos como modelos em vez de documentos (capturando
requisitos e design, por exemplo) contendo figuras de modelos,
implicitamente suporta essa possibilidade.
Pontos de Vista e Visualizações
Um ponto de vista, como o nome diz, é uma posição de notação a partir da qual alguns aspectos
ou preocupações com o sistema (ou o conjunto de modelos representando o sistema)
ficam visíveis, indicando o aplicativo de um conjunto de conceitos e regras para formar
um filtro conceitual. O termo "perspectiva" é utilizado de forma semelhante,
para descrever uma maneira de visualizar e entender modelos que servem melhor às muitas
diretrizes diferentes e preocupações de diversos investidores.
As visualizações são projeções de modelos que mostram entidades que são relevantes
de um ponto de vista ou perspectiva específicos.
Na MDD, os pontos de vista e as visualizações são utilizados para separar preocupações, por exemplo,
para lidar com a estrutura lógica independentemente da estrutura física e independentemente
da estrutura do processo. O mais próximo que os modelos estiverem do domínio do problema,
mais fortemente os pontos de vista ou as perspectivas mapearão para as preocupações
de negócios dos investidores; na medida em que os modelos são desenvolvidos mais perto da forma
executável, mais preocupações computacionais são introduzidas. Nos dois casos, o objetivo é não simplesmente
produzir ilustrações passivas, mas modelos que são, pelo menos potencialmente, geradores de implementações
que satisfaçam essas preocupações separadas.
Elaboração e Tradução (Transformação)
Esses termos são freqüentemente utilizados informalmente para distinguir entre as mudanças do modelo
feitas a mão (elaboração) e as mudanças de modelo feitas por uma ferramenta (tradução). No
RUP, a elaboração tem um significado formal bem diferente - é o nome de uma fase
do ciclo de vida - mas nesta seção, estamos o utilizando informalmente para ilustrar
abordagens aparentemente diferentes para a evolução dos modelos.
Há também um senso de tamanho de etapa diferente na conversão e elaboração
- um senso de que um modelo é elaborado em várias etapas pequenas até que tenha
detalhes suficientes (incluindo detalhes de linguagem, infra-estrutura ou sistema operacional)
para gerar códigos a partir deles, seja por uma ferramenta ou manualmente. Manualmente,
queremos dizer que um humano pode olhar para o modelo e escrever em Java, C++ ou outras linguagens,
possivelmente elaborando mais no processo. Em contraste, na conversão, o modelo,
ainda no nível de abstração imaculado pelas preocupações com a linguagem, a infra-estrutura
ou o sistema operacional, é convertido em algo que executa e produz o resultado desejado
com pouca ou sem elaboração adicional. Observe que o resultado desejado inclui o desempenho
e outras características não funcionais.
Portanto, está implícito nesta abordagem que as preocupações arquiteturais cruzadas
estão direcionadas para o modo em que o modelo é construído e o modo em que ele descreve
os requisitos do recurso.
Outra palavra,
transformação, entrou em uso para descrever o processo para gerar um modelo de destino a partir de um modelo de origem,
seguindo um conjunto de regras e trabalhando de acordo com um conjunto de
parâmetros. Observe que utilizamos o termo "modelo" aqui do mesmo modo
que no RUP, então o modelo de destino poderia ser os elementos de implementação, por
exemplo, código ou texto. É claro, a transformação pode ser feita a mão, que faz
transformações sucessivas (incluindo detalhes) equivalentes à elaboração e as regras
podem ser muito complexas e enraizadas na profunda experiência da tecnologia e do domínio
disponíveis. No entanto, o significado padrão é que a transformação é feita
automaticamente e é examinada novamente na próxima seção na Arquitetura Dirigida
do Modelo®.
Observe que a idéia de transformação simplesmente envolve um modelo de origem e um modelo
de destino. O caso comum é que o modelo de destino é menos abstrato que o modelo de origem,
ou seja, o destino é de alguma maneira mais específico que a origem, mas isso não está
implícito na idéia de transformação. Observe que a transformação também pode incluir
detalhes em um modelo, produzindo um modelo de destino que seja mais refinado ao
permanecer amplamente no mesmo nível de abstração em que nenhuma informação relevante
à outro domínio seja introduzida. Contraste isso com uma transformação que produza
códigos a partir de um modelo de UML, muitas coisas são introduzidas neste modelo de destino
que não são do interesse do investidor de negócios, já que o comportamento requerido e as características
não funcionais são mantidas.
A habilidade de perceber o ideal da conversão depende dos recursos da ferramenta e nossa habilidade
de codificar, capturar e reutilizar o conhecimento empregado por um humano experiente. A quantidade de conhecimento que deve ser capturada e codificada depende do nível de abstração a partir do qual fazemos nossa etapa de conversão
- quanto mais alto o nível, mais conhecimento e mais dependência de domínio, normalmente.
Em MDD, tentamos levantar o nível de abstração a partir do qual podemos automaticamente
gerar um sistema operacional. Um modelo é elaborado ao ponto em que pode ser utilizado
para gerar algo. Em seguida, a forte preferência é que a saída não tenha que ser
mais elaborada para ser executada. Além disso, nossa ambição é fazer a elaboração
anterior, o mais rápido possível, por meio de transformações automatizadas sucessivas. Assim, as duas abordagens convergem: a tradução é realizada por etapas de transformação sucessivas, automatizadas o mais rápido possível. A transformação final para o sistema em execução ocorre com a descrição do modelo ainda em um alto nível de abstração
e com a tecnologia, infra-estrutura e seleções de linguagens de destino codificadas no mecanismo de transformação
e as regras e dados fornecidos para ele.
Um benefício adicional da MDD é que esperamos poder reutilizar transformações,
fazendo com que elas codifiquem o conhecimento de plataforma e de domínio e as boas práticas
por meio da criação por especialistas nos domínios correspondentes. Desse modo, facilitamos a
reutilização por desenvolvedores menos habilidosos e evitamos a recriação de ponto de partida com cada
novo aplicativo.
O Que é um Alto Nível de
Abstração? 
Há algumas maneiras de ver isso. Uma é junto com o espectro da linguagem e
estamos vendo emergir formas de UML executável, por exemplo. Outra é a partir
da perspectiva de engenharia de domínio em que os conceitos de linguagem e modelagem
podem ser especializados para o domínio. Por exemplo, UML é uma linguagem de finalidade
geral, então, junto com essa dimensão você localiza a utilização de
Perfis UML
em especializar a utilização de UML. Outra maneira é a necessidade sentida de evitar
modelos específicos para fornecedores e específicos para infra-estrutura para permanecer aberto para
nova tecnologia.
Em termos de expressão de dinâmicas detalhadas, o trabalho feito emSemânticas
de Ação UML
tornou possível formas executáveis de UML, mas a sintaxe concreta e a notação
não são padronizadas e o nível de Semânticas de Ação é parecido para outras
linguagens OO. Portanto, UML mais Semânticas de Ação provavelmente não é
a resposta final, mas é uma indicação de para onde as coisas estão indo.
Concluímos que um modelo expresso em UML, ou utilizando um perfil UML, que não contém
elementos dependentes do fornecedor, não depende de uma plataforma de infra-estrutura
específica, como J2EE ou Microsoft® .NET, e é semanticamente completo em estrutura
e comportamento sem recorrer a uma linguagem de procedimento específica (Java, C#, ...) e está em um alto nível de abstração por esta definição, embora a questão do nível de Semânticas de Ação permaneça.
A partir de uma perspectiva de domínio do problema, ou seja, o ponto de vista do usuário ou do cliente de negócios,
uma solução possível e atraente é a formulação de linguagens de modelagem específicas do
idioma. Essas são linguagens abstratas, no sentido de que são expressas em termos
e conceitos familiares aos trabalhadores do domínio específico, ainda são completas
em sua habilidade de expressar dinâmicas de modelo ainda tendo como base a UML.
Como isso esta relacionado ao RUP?
O relacionamento dos Modelos de Análise, Design e Implementação do RUP ilustra essas
idéias: o Modelo de Análise
representa uma visão anterior de como o comportamento expresso em casos de uso será
realizado; é naturalmente inclinado descritivamente na direção do domínio do problema
sendo abordado e as Classes de
Análise
que ele contém são consideradas agrupamentos conceituais das responsabilidades e do comportamento
requeridos. O Modelo de Análise não está normalmente completo o suficiente para executar, exceto, talvez,
em uma experiência pensada por um humano lendo o modelo e preenchendo os espaços
porque muita coisa não é dita. Em vez disso, o Modelo de Análise tem que passar
por um processo de refinamento, incluindo detalhes e precisão, resultando no
Modelo de Design.
O RUP permite que um projeto mantenha um Modelo de Análise separado ou considere
o Modelo de Análise como algo que evolui para o Modelo de Design. O processo de
refinamento é descrito de alguma forma nas atividades do RUP com a interpretação
padrão que os humanos exercendo as funções de Arquiteto e Designer de Software
executarão nesta evolução, provavelmente com considerável assistência de ferramentas.
Observe que este refinamento pode ser considerado como uma seqüência das transformações de modelo,
algumas das quais podem ser potencialmente automatizadas, por exemplo, na aplicação de padrões
de
análise
e design
na Análise Arquitetural das atividades do RUP e em Identificar Mecanismos de Design.
Quando o Modelo de Design está Completo?
O Modelo de Design evolui durante a vida do projeto, por meio de várias iterações; portanto, quando o Modelo de Design (ou alguma parte dele) consegue ser transformado em código, ou seja, quando podemos começar a produzir
Elementos de Implementação e integrá-los em Construções interessantes do sistema? O RUP oferece alguma orientação sobre
Mapeando do Design ao Código,
mas fundamentalmente não há respostas rígidas e rápidas. Mova-se para a implementação quando,
por meio da revisão, por exemplo, julgar que pode e esse ponto pode variar consideravelmente
entre as organizações e os projetos. O RUP oferece várias maneiras para prosseguir
do design para o código, duas das quais discutimos aqui para ilustrar como as decisões sobre
a integridade do design são tomadas:
1. Esboço e Código
O RUP diz: "Uma abordagem comum do design é fazer um rascunho do design
em um nível muito abstrato e, em seguida, mover diretamente para o código. A manutenção do modelo
de design é manual."
Ser bem-sucedido com essa abordagem requer que o desenvolvedor seja capaz de unir
o intervalo de abstração entre os níveis de design e implementação. Freqüentemente,
a manutenção do modelo de design é uma preocupação secundária e o código se torna
o foco!
2. RTE (Round-Trip Engineering) com o Modelo de Design de Evolução Única
O RUP diz: "Nesta abordagem, há um único Modelo de Design. Os esboços iniciais
dos elementos de design evoluem para o ponto em que podem ser sincronizados com o código."
Aqui os desenvolvedores fecham o intervalo de abstração com uma seqüência de etapas de modelagem.
A diferença entre esta abordagem e o "esboço e código" é que as etapas intermediárias
são manifestadas e, no final, a versão abstrata do modelo de design desapareceu.
Em ambos os casos, o valor potencial de um modelo de design abstrato é perdido: no
"esboço e código" porque o modelo de design abstrato normalmente não é
mantido e, com o tempo, perde o contato com o código e com o "modelo de design de
evolução única" porque a versão abstrata desaparece. Mesmo que uma versão inicial
seja mantida, normalmente segue o mesmo destino que o modelo de design de esboço e de
código. Observe que o nó de extremidade para o modelo de design com RTE é realmente a
visualização do código e uma visualização semelhante pode ter a engenharia revertida a partir
do código produzido no esboço e código com as ferramentas apropriadas. No RUP, suavizamos a
perda do modelo de design abstrato, até certo ponto, capturando visualizações arquiteturais
significantes e design rationale, em pontos críticos, no Documento de Arquitetura de Software.
A MDD oferece a esperança de que o modelo de design abstrato se tornará fundamental para a
geração de código e longevidade. Ela se torna a base principal para manutenção e,
na verdade, pode ser a única base para manutenção. Oferece também uma definição clara
do nó de extremidade para o design, ou seja, o ponto em que, no que se refere
ao mecanismo de transformação, o modelo está completo, consistente e sem ambigüidade
para ser transformado em um sistema executável. Até que ponto o modelo pode ser abstrato
depende da tecnologia disponível e o conjunto de ferramentas (por obter um exemplo, consulte
Tour: Visão Geral do Arquiteto de Software Rational) e também pode ser dependente do domínio.
Observe que no que se refere à MDD, isso é simplesmente outra transformação
(design para código), mas uma transformação importante que passa pelos níveis de abstração.
A próxima seção descreve um padrão de estrutura emergente para MDD, uma iniciativa
do OMG (Object Management Group) chamada MDA® (Model Driven Architecture®).
MDA (Model Driven Architecture)
Motivação 
MDA é uma iniciativa do OMG, um consórcio do segmento de mercado com cerca de 800 membros
com a missão de estabelecer diretrizes e especificações padrão para fornecer uma
estrutura neutra do fornecedor para o desenvolvimento do aplicativo e encorajar
a interoperabilidade nas principais plataformas de infra-estrutura de hardware e software.
A Unified Modeling Language é um produto do OMG. Agora, o OMG promove a MDA como
uma especificação de carro-chefe e com a posição do OMG como o promulgador
de padrões práticos com a intenção de serem suportados pelo IC do segmento de mercado, prática,
produtos e ferramentas e, observando o sucesso da UML, vale a pena estudar a MDA. Há uma riqueza de
informações em MDA, incluindo o Guia de MDA mais recente[OMG03],
no Web site
do OMG.
Há também vários livros disponíveis como [FRA03],
[KLE03], [MEL04] e muitos artigos, como "An MDA Manifesto" de Grady Booch, Alan
Brown, Sridhar Iyengar, James Rumbaugh e Bran Selic no The MDA Journal, Maio de
2004.
Idéias de Núcleo do MDA

A MDA apresenta alguns conceitos específicos e terminologia que a distingue das abordagens
mais gerais para MDD e isso é definido e discutido nas seguintes seções.
Construindo nos Padrões Existentes
A MDA está apoiada pelos padrões OMG existentes, incluindo:
- O MOF (Meta-Object Facility) - Além de definir uma linguagem para a construção
de metamodelos, por exemplo, UML e CWM, o MOF define uma estrutura para implementar repositórios para modelos e metamodelos, permitindo uma abordagem consistente para manipulação desses modelos ao
utilizar a MDA. O MOF é uma tecnologia essencial para MDA.
- A UML (Unified Modeling Language) - Os
PIMs,
PMs e PSM
s são definidos na UML, que é a notação fundamental para MDA.
- XMI (XML Metadata Interchange) - XMI define um formato de intercâmbio do modelo UML
com base em XML.
-
O CWM (Common Warehouse Metamodel) - Como a UML é para a modelagem do aplicativo,
é o CWM para a modelagem de dados.
Independência da Plataforma
Uma noção intuitiva de uma plataforma
é que ela suporta uma camada arquitetural mais alta por meio de provisão de serviços
com um conjunto bem definido de interfaces que ocultam os detalhes da implementação.
A definição do OMG (no Guia de MDA) da plataforma é:
"Um conjunto de subsistemas/tecnologias que fornecem um conjunto coerente de funcionalidade
por meio de interfaces e padrões de uso especificado que qualquer sistema que dependa da plataforma
pode utilizar sem se preocupar com os detalhes de como a funcionalidade fornecida pela plataforma
é implementada."
Isso é parecido como o conceito de uma
camada
utilizado no RUP.
A idéia de independência da plataforma é levemente escorregadia: é uma qualidade
ou característica de um modelo, por exemplo, pode-se dizer que um modelo é independente
de uma plataforma específica quando ele não contém referências a serviços ou o recurso
fornecidos por essa plataforma. No entanto, a instrução é relativa
porque é difícil contemplar uma forma absoluta de independência da plataforma.
O Guia de MDA reconhece isso e também admite a possibilidade de graus de independência
da plataforma em relação a uma plataforma específica em que, por exemplo, um modelo utiliza
uma forma generalizada de um recurso em uma plataforma específica.
A realização da independência da plataforma é assistida pela evolução das plataformas
como J2EE, .NET e WebSphere, para aumentar os níveis de abstração em termos do que é
exposto para aplicativos. Isso torna a identificação das construções neutras da plataforma
muito mais tratáveis e as transformações específicas da plataforma que as convertem muito mais
simples e fáceis de gravar.
PIM (Platform Independent Model)
Podemos dizer que um modelo é um PIM em relação a uma plataforma específica quando
não está ligado ao uso dessa plataforma e poderia ser utilizado com qualquer plataforma
desse tipo. Em uma seção anterior, discutimos a idéia de um alto nível de abstração
e concluímos que um modelo expresso em UML (ou utilizando um perfil UML), que não contém
elementos dependentes do fornecedor, não é dependente de uma plataforma de infra-estrutura
específica e é semanticamente completo em estrutura e comportamento sem recurso para uma
linguagem de procedimento específico que era, pelo menos de modo nocional, executável e em
alto nível de abstração. Esse modelo é independente da plataforma?
Sim e não. Não, em relação a talvez uma Máquina Virtual UML imaginária e,
sim, em relação a toda uma classe de plataformas de que uma máquina virtual
dependeria.
Modelo da Plataforma 
O modelo da plataforma é o conjunto de conceitos (representando peças e serviços),
especificações, definições de interface, definições de restrição e quaisquer outros
requisitos que um aplicativo precisa para utilizar uma plataforma específica. Na MDA,
os modelos da plataforma são detalhados e formalizados em UML, por exemplo, e disponibilizados
em um repositório compatível com MOF. Por exemplo, os modelos da plataforma poderiam ser construídos
para J2EE ou .NET, entre outros.
PSM (Platform Specific Model) 
Um PIM é transformado em um ou mais PSMs pela adição de informações que o tornam
específico para uma ou mais plataformas específicas. O PIM e o PSM
ainda especificam o mesmo sistema, mas o PSM é restrito a uma tecnologia específica e
pode conter elementos específicos da plataforma. Observe que não há implicação de que
uma etapa de transformação (PIM a PSM ou sua plataforma associada) é grande
ou pequena. Uma transformação envolvendo o aplicativo de um pequeno conjunto de padrões
refina o modelo e, de algum modo, o torna mais específico; isso enfatiza a relatividade
dos termos PIM e PSM.
Pontos de Vista e Visualização
Esses termos são utilizados da mesma forma na MDA conforme descrito para MDD:
- Um ponto de vista, como o nome diz, é uma posição nocional a partir da qual alguns
aspectos ou preocupações com o sistema ficam visíveis, afirmando que o aplicativo de
um conjunto de conceitos e regras formam um filtro conceitual. Como algumas informações
sobre o sistema são omitidas, é uma forma de abstração. O termo perspectiva é utilizado de forma semelhante.
- A partir de um ponto de vista, é possível consultar visualizações, que são projeções de modelos,
mostrando entidades que são relevantes a partir desse ponto de vista.
A MDA especifica três pontos de vista em um sistema: um ponto de vista independente de computação,
um ponto de vista independente da plataforma e um ponto de vista específico da plataforma.
Ponto de Vista Independente da Computação
A partir do ponto de vista independente da computação, você está preocupado com o contexto
para o sistema, os requisitos e restrições em que deve operar e as coisas no ambiente
com que deve interagir. A partir desse ponto de vista,
não é possível consultar detalhes da estrutura ou do comportamento do sistema.
O CIM (Computation Independent Model) é uma visualização
do sistema ou do futuro sistema a partir do ponto de vista independente da computação. O
CIM é semelhante em conceito à combinação do Modelo de Domínio no RUP, que é o conjunto
de artefatos, incluindo o Glossário de Negócios e o Modelo de Análise de Negócios,
que é a saída de Detalhes do Workflow: Desenvolver um Modelo de Domínio (na Modelagem
de Negócios) e o Modelo de Caso de Uso, que é a descrição computacionalmente independente do
comportamento do sistema. O CIM, que é expresso na linguagem
dos especialistas em assunto ou domínio, é um link importante na identificação
durante a Análise e o Design das principais abstrações no futuro sistema.
Ponto de Vista Independente da Plataforma
O ponto de vista independente da plataforma é relativo a uma plataforma específica. A partir desse ponto de vista,
é possível consultar a estrutura e o comportamento de um sistema sem os detalhes
dessa plataforma. O PIM é uma visualização do sistema do ponto de vista independente
da plataforma.
Ponto de Vista Específico da Plataforma
A partir do ponto de vista específico da plataforma, também relativo a uma plataforma específica, é possível
consultar o que estava visível a partir do ponto de vista independente da plataforma, mas agora com os detalhes do
uso da plataforma revelados. O PSM é uma visualização do sistema a partir de um ponto de vista
específico da plataforma.
Automação da Transformação 
A idéia de transformação é fundamental para a transformação de MDA e do modelo e é
definida simplesmente como "o processo de conversão de um modelo para outro modelo
do mesmo sistema". MDA também define um pequeno padrão para visualizar
a conversão e ilustrar a utilização de algumas terminologias que vimos:
O Padrão MDA
A intenção do diagrama é mostrar que a transformação é uma coisa de primeira classe:
a transformação leva o PIM e as outras informações e os combina para produzir o PSM.
A transformação do modelo pode, é claro, ser feita manualmente. Isso é um pouco diferente
do modo que o design de software sempre funcionou. Mesmo aqui, MDA é útil no delineamento
e formalização da idéia de transformação, o processo e as informações adicionais
a serem utilizadas. MDA também sugere que um registro da transformação seja
produzido; isso fornece forte rastreabilidade do PIM para PSM porque deveria
incluir um mapa dos elementos do PIM para os elementos do PSM. A maior alavanca vem da habilidade de automatizar transformações, mesmo se somente parcialmente, gerando as mesmas vantagens que vêm da substituição da programação
do montador com linguagens de alto nível.
Como a Transformação é Realizada?
MDA não prescreve uma única maneira de fazer a transformação: um mapeamento, dirigido
pela escolha de uma plataforma, é preparado para fornecer uma especificação de como transformar
um PIM em um PSM para essa plataforma; esse mapeamento resulta em uma definição de transformação
(talvez expressa como um conjunto de regras de transformação), possivelmente com parâmetros de
transformação, escritos em uma linguagem de definição de transformação.
Observe que o OMG emitiu um RFP (RFP de Consulta/Visualizações/Transformações MOF 2.0) na
expectativa de padronização de (para o MOF) linguagens para criar visualizações de
modelo, consultando um modelo e escrevendo definições de transformação. O Guia de MDA
descreve várias abordagens para transformação, incluindo:
- Transformação de Metamodelo - Esta abordagem sugere que há um metamodelo
MOF em nível de PIM no idioma em que o PIM é construído. Igualmente, para a plataforma
escolhida, há um metamodelo em nível de PSM na linguagem em que um PSM pode
ser construído. Um mapeamento entre os dois metamodelos pode ser utilizado
para construir uma definição de transformação; isso é utilizado para transformar PIM
em PSM.
- Marcação - Um mapeamento para a plataforma escolhida é preparado. Esse mapeamento
é utilizado para construir uma definição de transformação que inclui um conjunto de
marcas que são utilizadas para marcar elementos do PIM, gerando um 'PIM marcado' e uma
definição do que fazer com os elementos marcados. O PIM marcado marcado
é transformado para produzir o PSM. A marcação é normalmente um processo
manual, mas a transformação subseqüente pode ser automatizada.
- Transformação do Modelo - O PIM é construído utilizando tipos independentes
da plataforma, também especificado em um modelo, em que os elementos no PIM são
subtipos dos tipos independentes da plataforma. Uma plataforma específica é escolhida,
associada a um conjunto de tipos específicos da plataforma. Um mapeamento é feito entre
os dois conjuntos de tipo, gerando uma definição de transformação, que está aplicada ao
PIM, produzindo um PSM expresso em subtipos dos tipos específicos da
plataforma. Essa abordagem é, de algum modo, parecida com uma transformação de metamodelo,
exceto que a transformação está restrita a tipos em um modelo em vez de conceitos
a partir de um metamodelo de MOF.
- Aplicativo Padrão - O PIM é construído utilizando um conjunto de tipos e padrões
abstratos que são independentes da plataforma. Para a plataforma escolhida, existem um conjunto
de tipos específicos para a plataforma e padrões. Um mapeamento é feito entre os dois tipos
e os conjuntos de padrões, fornecendo uma definição de transformação a ser aplicada ao PIM. Isso produz um PSM onde os padrões foram feitos especificamente para a plataforma.
Para obter detalhes adicionais, o leitor deve consultar o Guia de MDA[OMG03].
Como a Transformação é Aplicada?
O cenário mais simples para o aplicativo de MDA é:
- Prepare um PIM
- Selecione uma plataforma
- Prepare um mapeamento se não existir um
- Aplique a transformação para produzir um PSM
- Transforme o PSM em código. Se o PSM não precisar de refinamento adicional e puder
ser implementado diretamente, é uma implementação, conforme definido na próxima seção
PSMs para outras plataformas podem ser gerados da mesma maneira.
Aplicativo Repetido do Padrão MDA
No entanto, o padrão MDA é condescendente com aplicativo repetido: um PSM gerado
em um nível se torna o PIM para o próximo, ou seja, para o próximo, altamente especializado,
escolha da plataforma. Observe que em MDD, como a descrevemos no RUP e a suportamos
com o conjunto de ferramentas IBM Rational, nossa preferência é minimizar o número de
etapas de refinamento, ou seja, prosseguir a partir de uma representação que esteja perto da instrução
do problema do cliente para um formulário executável o mais diretamente possível.

Aplicativo Repetido do Padrão MDA
Transformação Geral Modelo a Modelo
Os mesmos conceitos podem ser aplicados a uma transformação geral, ou seja, qualquer modelo
para qualquer modelo. Se, por exemplo, existem dois metamodelos cujas linguagens são
utilizadas para expressar os modelos, em seguida, em princípio, um mapeamento pode ser feito, gerando
uma definição de transformação. Isso é aplicado do modo que já vimos para a transformação
de PIM em PSM.
Implementação 
O Guia de MDA utiliza a "implementação" de um modo semelhante para o Modelo de
Implementação do RUP. É uma especificação de todos os
Elementos de Implementação
necessários para construir, implementar, instalar e operar o sistema.
Um PSM pode ser uma implementação ou pode exigir refinamento adicional antes que
possa ser transformado em código. Observe que a produção de uma implementação PSM
pode ignorar a etapa de manifestação do PSM e ir direto para o código. Nesse caso,
o PIM mais abstrato pode ser transformado diretamente em código pelo mecanismo de
transformação. Uma visualização do código ainda pode ser fornecida para o desenvolvedor
para ajudar a compreensão, mas isso pode ter a engenharia revertida a partir do código.
Supostos Benefícios 
Portabilidade e Interoperabilidade
MDA oferece a esperança de controlar o gasto e a perturbação da separação de tecnologia,
permitindo um conjunto relativamente estável de PIMs a ser redirecionado para qualquer
nova tecnologia que seja exigida. A expectativa é de que, com a crescente aceitação
de MDA, os desenvolvedores de nova tecnologia também entregará mapeamentos para que as
transformações possam ser feitas rapidamente.
Estendendo os mapeamentos PIM-PSM para duas plataformas, a MDA sugere que 'pontes'
possam ser construídas entre os dois PSMs e finalmente entre as duas implementações
para que um PIM possa ser distribuído entre as plataformas. A maioria das empresas
enfrenta a realidade de desenvolvimento para ambientes heterogêneos com uma combinação
de tecnologias novas e antigas, então essa habilidade de realizar interoperabilidade é
potencialmente de grande benefício.
Custo do Ciclo de Vida Reduzido

Produtividade 
O foco do desenvolvimento com MDA se torna o PIM mais abstrato. Com um poderoso conjunto
de ferramentas para gerar um PSM (ou um código), como um ambiente deve ser mais produtivo
do mesmo modo que trabalhar em uma linguagem de alto nível é mais produtivo que trabalhar
no montador, considerando especificamente que um PIM, ou algo assim, é freqüentemente
desenvolvido mesmo assim, por exemplo, servindo como o Modelo de Design no RUP.
O ganho de produtividade depende criticamente de quanta intervenção manual é necessária
no processo de transformação.
Qualidade 
Idealmente, em MDA, o destino de manutenção é o PIM. Conseqüentemente, com a condição
de que o PIM seja bem arquitetado, deve haver menos defeitos na vida do produto
porque há menos oportunidades para um humano injetá-los e os defeitos que são descobertos
deveriam ser mais baratos para corrigir, por meio do benefício da transformação
automatizada. A concentração no PIM também está mais alinhada com as preocupações
do domínio, então deveria haver uma probabilidade maior de satisfazer as necessidades
dos usuários.
| |
|