UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO Contribuições do MDA para o desenvolvimento de software Anna Carla Mohr Verner Helder Eugenio dos Santos Puia Florianópolis, dezembro de 2004.
Contribuições do MDA para o desenvolvimento de software Uma das principais propriedades que um software deve apresentar é capacidade a mudanças e adaptabilidade tanto a requisitos quanto ao ambiente computacional no qual está inserido. Sabe-se que não é nada trivial atingir essa capacidade, principalmente mantendo produtividade. O mercado do software hoje exige que as empresas desenvolvam software cada vez mais complexo, em menos tempo. E não só isso, a cada novo dia surgem novas tecnologias, e os sistemas precisam acompanhar essas mudanças. Este é um dos maiores problemas no desenvolvimento de software atualmente, como desenvolver software complexo, com qualidade e em pouco tempo. E, além disso, existem outros problemas como manutenibilidade e gerenciamento da documentação, e características que a maioria dos sistemas devem possuir como interoperabilidade e portabilidade. Implementar um sistema com todas estas características demandam um grande esforço. Visando minimizar este esforço, há alguns anos atrás a OMG (Object Management Group) lançou uma nova proposta de desenvolvimento de sistemas chamada MDA (Model Driven Architecture). O MDA, Model Driven Architecture, é um framework que promove o uso de desenvolvimento de modelos independentes dos detalhes da implementação dando ao sistema uma flexibilidade maior. MDA propõe uma forma de desenvolvimento onde o foco está nas regras de negócio do sistema e de modelos que expressem estas regras. Todos os aspectos tecnológicos do sistema seriam adicionados a esses modelos em uma transformação. A maior parte do processo é automatizada não só mantendo como aumentando a produtividade e qualidade do sistema. Model Driven Architecture O MDA é um framework para desenvolvimento de software. A chave do MDA é a importância dos modelos no processo de desenvolvimento. Com MDA o processo de desenvolvimento de software é dirigido pela modelagem do sistema. MDA define uma abordagem à especificação de sistemas de informação que separa a especificação das funcionalidades do sistema, da especificação da
implementação dessa funcionalidade numa plataforma específica, abstraindo a maneira como o mesmo usará as potencialidades de sua plataforma. O objetivo é automatizar algumas das etapas do processo de desenvolvimento de software incluindo a geração de código para a plataforma escolhida. Arquitetura O coração da arquitetura está no centro da Figura, é baseado nos padrões de modelagem da OMG. Outras duas camadas completam a arquitetura. A primeira representa as plataforma que são alvo do framework atualmente e a segunda representa os serviços que podem existir independente da plataforma adotada. O núcleo do MDA compreende um conjunto de UML profiles, desenvolvidos pela OMG, cada um abrangendo determinada área do processo de desenvolvimento. Esses profiles representam as características comuns de todos os ambientes middleware apropriados, porém será independente de qualquer plataforma específica. A Camada intermediária compreende os ambientes middleware que são alvo do MDA atualmente: O ambiente web-service, CORBA principalmente CORBA Component Model ou CCM, Java incluindo EJB, C#,.NET, XML/SOAP. Se sua plataforma favorita não estiver nessa lista ou se novas plataformas surgirem os membros da OMG irão adiciona-las o mais breve possível. A última camada corresponde aos pervasives services, todas as aplicações, independente do contexto, dependem de um conjunto de serviços essências. Esses
PSM serviços variam de acordo com a origem do sistema, mas normalmente incluem serviços de diretórios, segurança, manipulação de eventos, persistência e transações. Esses serviços estão representados na arquitetura no anel mais externo. Ainda que com mesmos objetivos, em termos de implementação esses serviços quando definidos e construídos em plataformas específicas possuem características que os restringem das demais plataformas. No framework MDA os pervasive services são representados no mais alto nível de abstração. A este nível de abstração, a maneira com que esses serviços serão implementados na plataforma específica ficará a cargo do framework deixando transparente o funcionamento para o desenvolvedor. Ciclo de Vida Historicamente sistemas têm sido desenvolvidos, gerenciados e integrados usando um grande número de tecnologias, ferramentas e middleware. O que temos visto ultimamente é uma movimentação gradual para modelos semânticos mais completos, bem como padrões de representação de comunicação de dados. O ciclo de vida do MDA não difere muito dos ciclos de vida dos modelos tradicionais. As mesmas fases podem ser identificadas. Uma das maiores diferenças está na natureza dos artefatos que são criados durante o processo de desenvolvimento. Os artefatos são modelos formais que podem ser entendidos pelo computador. Na Figura abaixo está representado o ciclo de vida do MDA, cada uma das esferas representa uma das etapas do processo de desenvolvimento, que é bastante similar às demais metodologias. A primeira etapa é o levantamento de requisitos, em seguida as etapas de análise, design, codificação, teste e implantação. O que difere são as saídas das etapas, que são representadas pelos quadrados, onde surgem novos conceitos e modelos, que serão vistos em mais detalhes mais a frente. Requisitos Analise Especificação De Requisitos Processo MDA Design PIM
. Funcionamento Para entendermos o funcionamento do MDA devemos conhecer os modelos definidos pela sua arquitetura. Esses modelos são à base do funcionamento do framework, o que torna possível o alcance dos objetivos propostos. PIM Modelo Independente de Plataforma Todo projeto em MDA começa com a criação do modelo independente de plataforma. O objetivo do PIM (Platform independent model) é expressar apenas as funcionalidades de negócio e comportamento, devendo ser construído por analista de negócio e de modelo, sendo o mais preciso possível. Esse modelo deve representar todas as características estáticas da aplicação. Outros diagramas UML, como diagramas de atividade e seqüência dão poder para representar as características dinâmicas. O PIM pode ser refinado tornando-se ainda mais precisos. Para isso podemos incorporar ao PIM alguns aspectos de tecnologia sempre abstraindo detalhes de alguma plataforma específica. Por exemplo, todos os ambientes permitem especificar padrões, alguns dos padrões de modelagem que são incorporados a todas as tecnologias foram também incorporados ao UML, tornando fácil à adoção de algum padrão de
desenvolvimento, ou seja, o PIM nada mais é do que um modelo UML que especifica apenas as funcionalidades de negócio da aplicação, desconsiderando qualquer característica da plataforma na qual o sistema será desenvolvido. Por sinal, para a elaboração do PIM não é necessário que a plataforma que será construída a aplicação esteja definida. Quando construímos uma aplicação baseada em MDA, devemos primeiramente construir um modelo independente de plataforma. Mas antes de transformar este modelo em um modelo específico de plataforma como CORBA ou J2EE, nós podemos determinar quais pervasive services devem ser referenciados para nossa aplicação. Como dito anteriormente Pervasive Services podem existir em qualquer aplicação independente do contexto no qual está inserido. Apenas quando as características e arquitetura dos pervasive services estiverem concluídas, o PSM (que será visto a seguir) deverá ser gerado. Isso mostra que MDA prevê geradores separados para cada componente do PIM, isto é, o núcleo da aplicação e os pervasive services. PSM Modelo Específico de Plataforma O PSM (Plataform specific model) é uma visão do sistema do ponto de vista específico da plataforma. Um PSM combina as especificações no PIM com os detalhes que especificam como esse sistema usa um tipo particular de plataforma. Para produzir o PSM é necessário escolher a plataforma alvo ou plataformas para os modelos da aplicação. Caso a ferramenta de desenvolvimento utilizada não saiba qual a plataforma e quais pervasive services serão utilizados, essas informações deverão ser fornecidas. Durante o mapeamento as características de tempo real e informações de configuração que projetamos de uma maneira geral são convertidas para formulários específico requeridos pela plataforma alvo. Através de um mapeamento padrão, as ferramentas automatizam as conversões possíveis deixando os pontos ambíguos para serem implementados a mão. As versões mais antigas do MDA podem requerer ajustes consideráveis, sendo que a quantidade diminuirá com os profiles e o amadurecimento dos mapeamentos.
Transformações O processo MDA se parece muito com o processo de desenvolvimento tradicional, a grande diferença e vantagem do processo MDA está na transformação de PIM para PSM, sendo que este processo pode e deve ser automatizado para que se obtenha todos os benefícios que o framework oferece. Ocorrem duas transformações essenciais no processo, a primeira é a transformação do PIM para PSM e a segunda de PSM para código. A transformação de PSM para código não é nenhuma novidade, uma vez que este modelo é muito próximo ao código. Essas transformações são baseadas em mapeamento que consistem em um conjunto de regras de transformação que são especificações não ambíguas de modo que o modelo possa ser usado para criar outro modelo. Em MDA, uma das características chave é a noção de mapeamento. Mapeamento é um conjunto de regras e técnicas usadas para modificar um modelo a fim de gerar outro. Para transformar um modelo em outro, utilizamos o que chamamos de Especificação de Transformação (Mapeamento). Esta Especificação de transformação deve possuir todas as informações relacionadas ao Modelo Independente de Plataforma
e também as informações relacionadas ao Modelo Específico de Plataforma. Como mostrado na figura acima. Um modelo é preparado usando tipos independentes de plataforma definidos. Os tipos podem ser parte de um framework. Os elementos no PIM são subtipos dos tipos independentes de plataforma. Uma plataforma específica é escolhida. Uma especificação de transformação é disponibilizada ou desenvolvida. Esta especificação de transformação define as regras de mapeamento entre os tipos independente para os tipos dependentes de plataforma. Os elementos do PSM são subtipos dos tipos específicos de plataforma. Além dos tipos independentes e dependentes de plataforma, também podem ser mapeados padrões de desenvolvimento que podem ser incorporados a aplicação. A figura abaixo sumariza o funcionamento do MDA, mostrando o fluxo básico do desenvolvimento de uma aplicação que adote o MDA. Como já citado anteriormente o processo inicia com o desenvolvimento do PIM. A partir deste será gerado o modelo, ou os modelos específico de plataforma para o ambiente computacional escolhido para a aplicação. Este modelo e outros como diagrama de atividades e de seqüência representam todas as características e funcionalidades da aplicação já incluindo as características da plataforma escolhida. Estes modelos devem possuir toda a informação necessária para a codificação, seja ela feita a mão, ou como se espera quando se adota um processo como MDA, que esta etapa seja ao máximo automatizada.
Como MDA pode ajudar na solução dos problemas atuais Em MDA o foco maior do desenvolvedor está no desenvolvimento do PIM, proporcionando com isso ganho na solução dos problemas como produtividade, portabilidade, interoperabilidade, entre outros. Produtividade Desde que o desenvolvedor possa trabalhar independentemente de detalhes específicos da plataforma alvo, há muitos detalhes técnicos que eles não precisam se preocupar. Esses detalhes técnicos são automaticamente adicionados na transformação de PIM para PSM. Isto pode melhorar a produtividade de duas formas. Em primeiro lugar o desenvolvedor tem menos trabalho porque os detalhes específicos da plataforma não precisam ser projetados e escritos. Estes detalhes estão
definidos no mapeamento das transformações. Em nível de PSM a muito menos código a ser escrito, porque a maior parte do código já é gerada a partir do PIM. O segundo melhoramento é conseqüência do desenvolvedor estar mais focado na produção do PIM, prestando mais atenção do negócio, na arquitetura e no modelo de objetos por traz do sistema. Engenharia de Software tem provado que projetar o sistema primeiro irá reduzir as possibilidades de erros arquiteturais do sistema. Portabilidade Com MDA a portabilidade é alcançada pelo foco do desenvolvimento nos PIM s, que são definidos independente de plataforma. O mesmo PIM pode ser ao mesmo tempo transformado em diversos PSM para diferentes plataformas. Tudo o que se especifica em nível de PIM deve ser completamente portável. A portabilidade está limitada as ferramentas de geração automática que estão disponíveis. Para as plataformas mais populares um grande número de ferramentas estão sendo disponibilizadas, para as menos populares deve-se ter uma ferramenta que suporte um plugin para definição de transformações e essas definições devem ser descritas manualmente. Para novas tecnologias e plataformas que irão chegar no futuro a industria de software precisa disponibilizar os mapeamentos de transformações a tempo. Isso nos permite rapidamente desenvolver novos sistemas com novas tecnologias baseadas nos modelos de PIMs já existentes. Pode-se obter uma aplicação portável, escolhendo tecnologias que possuem esta característica, como Java, ou mesmo criando várias versões da aplicação, uma específica para cada ambiente computacional que se espera que aplicação funcione. Neste caso ser capaz de desenvolver aplicações a partir de modelos que não levam em consideração os detalhes de ambiente é de grande valor. Interoperabilidade A figura abaixo mostra vários PSM gerados a partir de um PIM e podem ter relações. Em MDA essas relações são chamadas de bridges(pontes). Quando os PSMs são alvos para diferentes plataformas eles não podem conversar diretamente um com outro, de uma forma ou de outra nós precisamos transformar os conceitos de uma
plataforma em conceitos usados para a outra plataforma. MDA resolve esse problema gerando não apenas PSM, mas também as pontes necessárias entre eles. PIM Primeira Transformação Primeira Transformação Segunda Transformação PSM PSM Bridge PSM Segunda Transformação Sendo capaz de transformar um PIM em dois PSM s alvos de duas plataformas, todas as informações que são necessárias para a construção das pontes entre os dois PSM s estão disponíveis. Para cada elemento de um PSM é conhecido o elemento no PIM que o originou. A partir do elemento PIM sabe-se qual é o elemento correspondente no segundo PSM. Pode-se então deduzir como os elementos de um PSM se relacionam com elementos de um segundo PSM. Desde que também se conheça todos os aspectos e detalhes técnicos de todos os PSM s, se tem todas as informações necessárias para gerar a bridge entre os dois PSM s. A interoperabilidade entre plataformas pode ser realizada por ferramentas que não geram apenas PSM, mas também as bridges entre eles, e possivelmente a outras plataformas também. Code Code Bridge Code Manutenção e Documentação O PIM é usado para gerar PSM e o PSM é usado para gerar código. O modelo é a exata representação do código. O PIM tem a função de documentar o mais alto nível de abstração que é necessário para qualquer sistema. A grande diferença é o que PIM não é abandonado depois de construído, mudanças realizadas no sistema são realizadas por mudança no PIM e feita uma nova geração de PSM e código.
Boas ferramentas, entretanto mantém esses elementos sincronizados, ou seja, qualquer alteração em qualquer um destes elementos refletira em alterações correspondentes nos demais. Em MDA a documentação de mais alto nível estará naturalmente refletindo a exata implementação do sistema, tornando assim a manutenção do sistema e da própria documentação menos custosa. MDA na Prática Pesquisamos três ferramentas, OptimalJ, XDE e AndroMDA, entre elas escolhemos OptimalJ, que comparada a AndroMDA é uma ferramenta mais completa, visto que dá suporte a todo o processo, desde a construção do PIM até a automatização do código e que em relação ao XDE o OptimalJ mostrar de forma mais clara todo o processo, principalmente as transformações, o que para fins didáticos se torna mais adequado. Além disso, o OptimalJ possuí todo o ambiente de desenvolvimento integrado, incluindo Sistema Gerenciador de Banco de Dados, Tomcat e Jboss. Iremos apresentar agora uma análise prática do processo MDA utilizando a ferramenta OptimalJ. Para tanto desenvolvemos uma aplicação de controle de compra e venda de mercadorias de uma loja fictícia. A aplicação é relativamente simples e foi desenvolvida sem nenhuma pretensão comercial, visando apenas à ilustração do paradigma. Aplicação de Controle de Compra e Venda de Mercadorias O exemplo que será explorado neste trabalho consiste em uma aplicação de controle de compra e venda de mercadorias que pode ser utilizado para qualquer estabelecimento com tal necessidade. A aplicação consiste em gerenciar as operações de compra e venda de um estabelecimento comercial qualquer, disponibilizando ao usuário as funcionalidades de cadastro de produtos e fornecedores, bem como o registro de uma compra e de uma venda realizando o controle de estoque. O usuário cadastra os produtos, clientes,
vendedores e os fornecedores e após disso está apto a registrar uma compra ou uma venda. No cadastro de produtos é possível cadastrar a porcentagem que se está acrescentando ao valor pago por ele, facilitando um possível desconto no momento da venda. Também é cadastrada a quantidade mínima de que o produto deve ter no estoque. Um produto é fornecido por apenas um fornecedor, sendo que um fornecedor pode oferecer vários produtos. A compra consiste na aquisição de uma lista de produtos de um determinado fornecedor para o estabelecimento, sendo confirmada o estoque deve ser atualizado. A venda é semelhante à compra, porém na venda o vendedor pode oferecer um desconto para o cliente com base na porcentagem que o produto está sendo vendido e o cliente adquire uma lista de produtos independente de fornecedores. Arquitetura da aplicação A figura abaixo representa a arquitetura definida para a aplicação de controle de compra e venda de mercadorias. APRESENTAÇÃO Struts SERVIÇO EJB Session Façade PERSTISTÊNCIA EJB Entity Bean Banco de Dados relacional Figura 13 - Arquitetura
Na figura acima os retângulos representam as camadas da aplicação e a tecnologia adotada nestas camadas. Mostras também a forma de persistência dos dados, que no caso é um banco de dados relacional e também como as camadas se interagem. A camada superior da figura é a camada de apresentação, está é responsável pela implementação da interface com o usuário, bem como as requisições do mesmo a aplicação. Como será uma aplicação WEB, contamos com o auxílio do framework Struts nesta camada, que dentre várias vantagens, adota o padrão MVC (model-view-controler), e dá suporte a internacionalização da aplicação, sendo que todos os labels das telas podem facilmente ser definidos em arquivos de propriedades, podendo ser criados um arquivo para cada língua que desejar. A camada intermediária é a de Serviço, ela é responsável pela implementação das regras de negócio da aplicação. Ela é implementada com componentes do tipo Session Bean, que funcionam como façade para os componentes de persistência e gerenciam o controle transacional e o acesso concorrente. Com isso tiramos a responsabilidade de implementação das regras de negócio das demais camadas, e também podemos facilmente distribuir a aplicação em diversos servidores. Podemos, por exemplo, ter um servidor para persistência e outro para as camadas de serviço e apresentação. A última camada é a de persistência, ela é responsável por todo acesso à base de dados. Usando componentes do tipo Entity Bean, abstraímos toda a complexidade do acesso a base de dados, deixando de trabalhar com linguagens de acesso aos dados (SQL) e passamos a trabalhar com objetos persistentes, ou seja, com esse tipo de componentes podemos trabalhar com uma base de dados relacional, como se fosse orientada a objetos. Aplicando o MDA No desenvolvimento da aplicação nós podemos identificar quais PSMs e modelos de código podem ser derivados e quais definições de transformações podem ser usadas para gerar os PSMs e o modelo de código. Todos os modelos MDA usados no exemplo são mostrados na figura abaixo. Os retângulos representam os modelos e as setas as transformações usadas.
Para iniciarmos o processo devemos construir um modelo de plataforma independente que compreenda o negócio da aplicação. Nosso PIM será um diagrama de classe UML. Esse será o único modelo a ser construído, os outros serão gerados. Cada camada usa uma tecnologia diferente e, portanto necessitamos de um modelo específico para cada camada (PSM). O primeiro modelo é um modelo relacional que descreve entidades e relacionamentos. O PSM para a camada intermediária, chamada de modelo EJB, é escrita em uma linguagem que é variante de UML. Ela usa classes, associações e assim por diante, como em UML, mas há um número de estereótipos definidos explicitamente para a plataforma EJB. O PSM para interface Web também é escrito por uma variante de UML. Essa linguagem usa estereótipos diferentes da variante UML utilizadas para o modelo EJB. Como três modelos PSMs precisam ser gerados, nós precisamos de três transformações de PIM para PSM: Transformação de PIM para modelo relacional: Essa transformação consiste em pegar o modelo de entrada e produzir um modelo escrito em termos de entidade-relacionamento
Transformação de PIM para modelo EJB: A transformação usa o PIM como entrada e escreve o modelo EJB com variantes UML usando estereótipos especiais para EJB. Transformação de PIM para modelo Web: O nosso modelo de entrada é o PIM novamente, a transformação utiliza variante UML agora com estereótipos especiais para a interface Web para gerar o modelo Web. Para cada PSM nós precisamos gerar código. O código foi incluído explicitamente para caber em nossa definição do modelo. Conseqüentemente, nós podemos falar dos modelos do código escritos em alguma linguagem de programação. Para a nossa aplicação exemplo nós temos três modelos de código, em SQL, Java e JSP. Conseqüentemente nós precisamos de três transformações de PSM para código: Transformação de modelo relacional para SQL: A transformação usa o modelo de entidade-relacionamento para gerar o modelo SQL. Transformação do modelo EJB para Java: Essa transformação pega o modelo EJB e produz um modelo Java. Transformação do modelo web para JSP e HTML: Essa transformação usa o modelo de web como entrada e escreve um modelo em JSP e HTML Tanto as transformações de PIM para PSM como de PSM para Modelo de códigos, são realizadas com base em templates que estão acoplados a ferramenta. Resultados e Conclusões Como nosso maior resultado tivemos um ganho de produtividade notável obtendo uma aplicação que atende aos mais conceituados padrões de qualidade e robustez, devido ao emprego de alguns padrões de desenvolvimento e a utilização de tecnologias bem conceituadas. Todo o processo de desenvolvimento foi direcionado a construção e refinamento do PIM, sendo que foram gerados automaticamente todos os demais modelos (ER, EJB e WEB). Durante toda a fase de design estes modelos permaneceram sincronizados, garantindo assim que nossa documentação de análise estivesse sempre atualizada, facilitando as alterações necessárias durante o desenvolvimento. Quase a totalidade do código necessário para nossa aplicação de exemplo foi gerada automaticamente, sendo que pequenas customizações foram necessárias,
especificamente para o cálculo do valor total para compra e venda, bem como a atualização do estoque para estes casos. Mas o que mais esperávamos com resultado deste estudo, é o real ganho de produtividade que uma tecnologia como MDA pode oferecer. Para termos uma visão mais realista deste possível ganho de produtividade, fizemos uma estimativa de horas, desconsiderando o uso de ferramentas de automatização do processo de desenvolvimento, mas considerando que teríamos uma equipe bem qualificada para o mesmo, bem como a estabilidade dos requisitos da aplicação. Para esta estimativa utilizamos a técnica de Use Case Points. Identificamos para nossa aplicação seis casos de uso, que são: Manter Vendedor. Manter Cliente. Manter Produto. Manter Fornecedor. Efetuar Compra. Efetuar Venda. Consideramos para esta estimativa que os casos de uso de 1 a 4 como sendo de complexidade simples, e os dois últimos de complexidade média. Levando em consideração todos estes parâmetros, e aplicando as regras determinadas pela técnica de Use Case Points chegamos a um total de 345 horas. Esta estimativa não é apenas para a construção da aplicação, mas sim para todo o processo de desenvolvimento de uma aplicação comercial. Dentre processo de desenvolvimento o MDA auxilia na parte de análise e design e construção. Estas duas etapas totalizam cerca de 275 horas. Com o auxilio de uma tecnologia como MDA foi possível reduzir o número de horas da etapa de análise, design e construção para cerca de 80 horas, considerando ainda a falta de experiência com a ferramenta escolhida, este número de horas poderia ser ainda mais reduzido se uma equipe mais experiente na ferramenta tivesse desenvolvido esta aplicação. Essa redução do número de horas trás vários benefícios a empresa de desenvolvimento, fazendo com que seu produto possa chegar antes ao mercado aumentando lucros e diminuindo custos. Porém devemos levar em consideração o fato de nossa aplicação ter em sua maioria características estáticas, uma vez que a ferramenta utilizada apesar de dar suporte aos modelos de representação das características dinâmicas não os utiliza na
geração do código, sendo que o mesmo teve que ser gerado manualmente, por isso acreditamos que à medida que complexidade aumente o ganho de produtividade decresça. São notáveis as vantagens que um framework como MDA trás ao processo de desenvolvimento de software. Como vimos durante o trabalho, podemos reduzir bastante o tempo de desenvolvimento, o que diminui os custos e possibilita que o produto chegue ao mercado ou ao cliente antecipadamente. Facilita também o gerenciamento da documentação, portabilidade, interoperabilidade e manutenção. Vale ressaltar que o MDA não é apenas um processo que pode ser facilmente adotado. Para que se tenha ganho total é necessário alguns subsídios que dão suporte ao desenvolvimento. O principal delas é a ferramenta escolhida. Já existem no mercado várias ferramentas que vendem este conceito. Algumas das ferramentas já estão bastante evoluídas, mas nenhuma delas aparentemente aborda MDA em sua totalidade. Em algumas delas nem todas as transformações estão previstas, em outras não é possível gerar código para o comportamento dinâmico da aplicação e há ainda aquelas em que não conseguimos gerar um modelo totalmente independente de plataforma. Apesar de ainda não implementar MDA em sua totalidade, acreditamos que em breve isso será possível, uma vez que as empresas estão investindo bastante nesta tecnologia e na evolução dos templates de transformação, que são à base do paradigma. Outra grande mudança em relação ao desenvolvimento como conhecemos hoje, são as pessoas que participam do processo. Cada vez mais será necessário ter pessoas que conheçam muito bem as regras de negócio da aplicação, e um número menor de pessoas, possivelmente menos especializadas para a codificação, visto que a maior parte do código será automatizado, com apenas customizações sendo feitas manualmente, e a medida que o processo e ferramentas amadurecerem, a tendência é que nenhuma customização manual seja necessária. A utilização da arquitetura MDA e ferramentas que implementam a mesma nos levam a conclusão que o código é importante, mas ele na verdade é resultado de uma transformação, isto é, o código é uma tradução da solução de negócio para determinado ambiente computacional, toda a inteligência de uma aplicação está nas suas regras de negócio.