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 resetar completamente uma instalação do Apache no Ubuntu

Quando eu estava experimentando o módulo python do Apache (mod_python), eu 'de alguma maneira' estraguei minha instalação do Apache. Os arquivos de configuração ficaram em um estado estranho, então eu excluí a pasta /etc/apache2, removi o Apache (através do dpkg) e o reinstalei. Mas o resultado não foi como esperado, a pasta /etc/apache2 não foi recriada na instalação.

Como interpretar e utilizar gráficos

A quantidade de uma única postagem nos últimos 5 anos de blog mostra o quanto estive focado em outras coisas e sem tempo para escrever aqui. Porém, no meio de uma pandemia e com a finalização do meu doutorado, acabei ficando com mais tempo e colocando como meta a volta das publicações aqui no blog.
Nunca antes na história desse país a população, de uma maneira geral, se preocupou tanto com gráficos, curvas, média e outras questões básicas da estatística. Assim, em tempos de coronavírus, essa postagem tem o objetivo de auxiliar que mais e mais pessoas consigam interpretar gráficos, fazer comparações e, inclusive, saber o melhor tipo de gráfico para usar em determinados casos.