Tópicos

Introdução Para o início da página

O RUP caracteriza muitos de seus artefatos como ../../glossary.htm#model -- This hyperlink in not present in this generated websitemodelos , 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) Para o início da  página

Modelos e Modelagem Para o início da página

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çõesPara o início da página

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) Para o início da página

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, ../../glossary.htm#transformation -- This hyperlink in not present in this generated websitetransformaçã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? Para o início da   página

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 ../../glossary.htm#UML_profile -- This hyperlink in not present in this generated websitePerfis 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?Para o início da página

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 ../../glossary.htm#analysis_pattern -- This hyperlink in not present in this generated websiteanálise e ../../glossary.htm#design_pattern -- This hyperlink in not present in this generated websitedesign na Análise Arquitetural das atividades do RUP e em Identificar Mecanismos de Design.

Quando o Modelo de Design está Completo?Para o início da página

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) Para o início da página

Motivação Para o início da página

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 Para o início da página

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 Para o início da página

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 PlataformaPara o início da página

Uma noção intuitiva de uma ../../glossary.htm#platform -- This hyperlink in not present in this generated websiteplataforma é 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 ../../glossary.htm#layer -- This hyperlink in not present in this generated websitecamada 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) Para o início da página

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 Para o início da página

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) Para o início da página

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çãoPara o início da página

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 Para o início da página

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 Para o início da página

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 PlataformaPara o início da página

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 Para o início da página

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, mostrando PIM e outras informações como entrada para uma transformação, PSM e registro de transformação como saída.

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?Para o início da página

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?Para o início da página

O cenário mais simples para o aplicativo de MDA é:

  1. Prepare um PIM
  2. Selecione uma plataforma
  3. Prepare um mapeamento se não existir um
  4. Aplique a transformação para produzir um PSM
  5. 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.

Mostra três aplicativos do padrão MDA, com o PIM inicial se tornando um PSM dependente da plataforma 1, em seguida, transformado novamente para ser dependente da plataforma 2 também, em seguida, transformado novamente para ser dependente das plataformas 1, 2 e 3.

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 Para o início da página

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 Para o início da página

Portabilidade e Interoperabilidade Para o início da página

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 Para o início da página

Produtividade Para o início da página

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 Para o início da página

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.

Rational Unified Process   2003.06.15