Reflexões sobre a especificação da OMG, Model Driven Architecture (MDA)?

Irei iniciar uma série de publicações envolvendo Arquitetura Orientada à Modelos (Model Driven Architecture, MDA), um padrão arquitetural, criado pela OMG (Object Management Group), que tem como objetivo realizar a separação entre: lógica de negócio da aplicação, evolução e manutenção do software. Através da utilização da MDA, é possível construir sistemas de forma rápida, consistente e independente de plataforma.

A especificação MDA é uma, nem tão nova assim, abordagem para o desenvolvimento de software, que ajuda empresas e engenheiros de software a gerenciar em larga escala projetos complexos de software, reduzindo custos de desenvolvimento enquanto permite que novas tecnologias sejam adicionadas ao projeto rapidamente.

Para entender melhor esta especificação é preciso, primeiramente, definir o Model da MDA. Após esta definição, serão mostrados o ciclo de vida MDA, os requisitos para implantar MDA e os benefícios desta implantação.

Modelo
Relacionamento entre modelo, sistema e
linguagem de modelagem.
Um modelo é sempre uma abstração de algo que existe no mundo real. Na engenharia de software, modelos descrevem a representação de softwares de um determinado domínio, onde essa representação do domínio é realizada através de uma linguagem de modelagem. Em MDA, a linguagem mais utilizada para descrever modelos, realizando a representação de um domínio, é a UML (Unified Modeling Language).

A base da MDA é a utilização de modelos no processo de desenvolvimento de software, por isso é importante que este conceito de representação, e de que forma esta representação é definida, esteja claro.

Ciclo de Vida
A arquitetura MDA é composta por três camadas:
  • Plataform Independent Model (PIM), um modelo de alto nível de abstração, independente de qualquer tecnologia de implementação. Todas as funcionalidades do sistema e restrições de negócio possuem modelos PIM.
  • Plataform Specific Model (PSM), um modelo associado a uma tecnologia específica (ex.: JAVA). Geralmente um PIM é transformado em um ou mais PSMs. Nesta camada detalhes inerentes à plataforma são definidos, seguindo as funcionalidades e regras de negócio definidas no PIM.
  • Código, é a especificação de fato do sistema em código-fonte. Cada componente do PSM é transformado em um conjunto de códigos.
Apesar destas camadas representarem níveis diferentes de abstração no sistema, é possível identificar, numa arquitetura MDA, a relação entre cada funcionalidade, não devendo haver inconsistências entre as camadas. Vale ressaltar a possibilidade de um mesmo modelo de negócio (PIM) poder ser gerado para diferentes plataformas sem a necessidade de alterar ou remodelar o sistema. Apenas mudanças nas características do sistema ou do negócio irão resultar em remodelagem no nível mais alto da arquitetura MDA, o PIM. Para gerar estes modelos a partir de um mesmo PIM são necessárias especificações diferentes para regras de transformação.


Resumidamente, as transformações são definidas como processos de geração de um novo modelo a partir de um outro modelo já existente. Em MDA, os modelos são transformados através de uma ferramenta que tem como uma entrada um PIM (modelo fonte) e o transforma em um, ou mais, PSM (modelo de saída). A outra ferramenta ou funcionalidade de transformação é converter o PSM para o código fonte. Esta transformação entre modelos é definida por "regras de transformação" dentro das ferramentas de transformação.

Requisitos
A MDA pode ser visualizada como um framework, onde blocos precisam se relacionar da maneira correta para o bom funcionamento do sistema ou processo. Segundo a OMG (2003), o seguintes requisitos devem ser atendidos nesta arquitetura:
  • Os diferentes níveis de abstração e seus modelos, descritos em uma linguagem de modelagem suportada, devem ser consistentes, precisos e completos, ou seja, compostos por informações totais do sistema.
  • É preciso definir a forma que um PIM é transformado em um PSM.
  • Utilização de uma linguagem para escrever estas especificações. Esta linguagem deve ser suportada por ferramentas de transformações, sendo assim, deve seguir os padrões de linguagens formais.
  • Utilização de ferramentas que implementam as definições de transformações. De preferência, estas ferramentas devem oferecer ao usuário flexibilidade ao direcionar os passos das transformações para necessidades específicas.
  • Utilização de ferramentas que implementam a execução da transformação de um PSM para código da tecnologia a ser utilizada.
Benefícios
Desenvolver software utilizando MDA permite alguns benefícios que justificam sua utilização. O primeiro deles é a automatização, que fica evidente quando pensamos no que acontece ao se desenvolver software da maneira tradicional e é preciso realizar uma migração de tecnologia, por exemplo. Sendo assim, as ferramentas de desenvolvimento MDA habilitam uma lista de plataformas para as quais a aplicação poderá ser gerada. O segundo ponto benéfico é a flexibilidade garantida aos desenvolvedores para a geração de código. Neste ponto o desenvolvedor se sente mais seguro em modificar ou adicionar melhorias ao software, pois pode seguir um modelo consistente. Outros benefícios são a facilidade de integração e a interoperabilidade no nível de modelos que geram código, evitando a interpretação de códigos complexos para identificar funcionalidades e extensões do sistema.

Na próxima publicação irei apresentar os padrões definidos pela OMG que suportam MDA, mas, caso alguém se interesse, pode começar a buscar sobre: UML, MOF (Meta Object Facility), QVT (Query, View, Transformation), OCL (Object Constraint Language) e XMI (XML Metadata Interchange).

Existe uma discussão sobre a efetividade da utilização de MDA na engenharia de software, muitos não acham que MDA seja uma forma válida de resolver os problemas atuais do desenvolvimento de aplicações, mas essa é uma outra história, que irei explicar quando falarmos sobre MDD.

Felipe Alencar

Felipe Alencar é doutorando em Ciência da Computação na UFPE, professor, desenvolvedor e acredita que só não virou jogador de futebol, surfista ou músico profissional por falta de tempo e talento.

Nenhum comentário:

Postar um comentário