Pular para o conteúdo principal

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.

Comentários

Postagens mais visitadas deste blog

Utilizando o padrão de referências da ABNT no Word

Uma importante funcionalidade do Microsoft Word é o seu Gerenciador de Fontes Bibliográficas. Para aqueles que estão escrevendo algum trabalho acadêmico ou científico, é possível cadastrar todas as referências do trabalho e no final gerar a listagem já enumerada dos documentos que foram consultados na pesquisa. Essa postagem traz os arquivos necessários e as instruções para facilitar essa etapa da elaboração.

Como elaborar um TCC em Sistemas de Informação

Alguns meses atrás estive na tão conhecida saga de elaboração do Trabalho de Conclusão de Curso, o TCC, e somente comprovei aquilo que eu via em forma de desabafo nas redes sociais e que tantos outros colegas de faculdade me falavam. Uma das definições mais aceitas por mim sobre o que é um TCC é a citada pela minha orientadora: "é uma gestação". E realmente, apesar de ter feito o meu em cerca de 1 mês (não recomendo isso para ninguém, mas era minha única saída para não ficar desempregado e sem a possibilidade de cursar meu mestrado, mas essa é outra história), um TCC bem feito deve ter seu cronograma definido para 6 meses, no mínimo, e isso deveria ser uma recomendação do Ministério da Saúde para que os graduandos não percam sua saúde mental.

Mininet: Uma Rede Virtual Instantânea no Seu PC

Baseado no texto de introdução presente no site oficial do Mininet (www.mininet.org) apresento esta ferramenta que possibilita a desenvolvedores e pesquisadores a criação de uma rede virtual realista, executando um kernel real, switch e código de aplicação, em uma única máquina (VM, cloud ou nativa), em segundos, com comandos simples.

A rede virtual criada pelo Mininet é escalável, uma rede definida por software em um único PC utilizando processos do Linux. Isso possibilita um meio inteligente de realizar testes e simulações de uma rede antes de implementá-la em meio físico, caso esse seja o objetivo.