Høringen av utvalgets forslag

O processo de desenvolvimento através da MDA é em tudo semelhante ao processo de desenvolvimento tradicional, atrás apresentado. As fases do processo são as mesmas e a diferença reside na natureza dos artefactos que são criados durante cada uma das fases. Na MDA, os artefactos são modelos formais que podem ser interpretados por um computador. O conceito chave, por trás desta metodologia é a clara distinção entre a especificação da

Model Driven Architeture

12

determinada tecnologia. Esta distinção é atingida separando os modelos independentes da plataforma (PIM) dos modelos dependentes da plataforma (PSM).

O processo de desenvolvimento (Figura 4)começa com a construção de um modelo com um

alto nível de abstração (independente de qualquer plataforma), designado de Platform Independent Model (PIM). De seguida, o PIM é transformado num ou mais Platform Specific Model (PSM). Por último, o PSM é transformado em código fonte [5].

Figura 4 – Processo de desenvolvimento da MDA

Platform Independent Model (PIM)

O primeiro modelo que resulta da utilização do processo de desenvolvimento da MDA, é um modelo com um alto nível de abstração que representa o sistema de um ponto de vista independente de qualquer tecnologia, ou seja, representa as partes da especificação do sistema que não mudam de uma plataforma para outra. A este modelo dá-se o nome de platform independet model (PIM).

Para o desenvolvimento de PIM’s é necessário uma linguagem de modelação formal e capaz de representar as especificações pretendidas, como por exemplo o UML. Os PIM´s podem ser utilizados em diversos níveis de abstração, nos níveis mais baixos representam apenas os comportamentos de negócio e em níveis mais avançados podem exprimir funcionalidades mais complexas do próprio sistema [5] [10].

A produção e o desenvolvimento dos PIM’s traz grandes vantagens, pois permite que a pessoa responsável por definir as funcionalidades se concentre apenas nas regras de negócio e que não tenha de ter em consideração nenhum detalhe tecnológico. Estes, permitem que a funcionalidade seja completamente isolada dos detalhes de implementação, o que garante a facilidade de migração para outras plataformas.

Model Driven Architeture

Platform Specific Model (PSM)

No próximo passo do desenvolvimento, o PIM é transformado num outro modelo designado de platform specific model (PSM). O PSM é um modelo computacional que combina a especificação do PIM em detalhes que descrevem como um sistema irá utilizar uma determinada tecnologia.

A transformação de PIM para PSM (transformações Model-to-Model), normalmente origina vários PSM’s que podem estar relacionados através de atributos, tipos, etc. (as relações entre PSM’s, em MDA, designam-se por Bridges) (Figura 5). Quando, através de um PIM, se geram PSM’s para tecnologias distintas, estes são completamente isolados e independentes (p.e. um PIM pode ser utilizado para gerar a mesma funcionalidade para .NET e Java) (Figura 5) [10].

Figura 5 – Transformações PIM - PSM

Código Fonte

O último passo no desenvolvimento, consiste em receber os PSM’s como input e produzir o

código fonte (transformações Model-to-Text) para uma plataforma em particular. Pelo facto de os PSM’s serem dependentes da tecnologia, esta transformação é feita de forma, relativamente simples. De notar também que, a transformação final de um PSM pode originar código fonte para diversas linguagens (semelhante ao que acontece na transformação de PIM para PSM).

Domain Specific Language (DSL)

Como já foi referido em 2.3 os modelos (PIM’s) são definidos/desenhados recorrendo uma linguagem formal que os permite ser suficientemente completos e consistentes para gerar PSM’s e, mais tarde, código final. A linguagem normalmente escolhida para este efeito é UML mas é possível utilizar outras linguagens ou até mesmo criar linguagens especificas para determinados contextos, as chamadas Domain Specific Languages (DSL).

Model Driven Architeture

14

Uma DSL é uma linguagem de programação ou de especificação utilizada num domínio ou problema em especifico que, normalmente, não pode ser utilizada fora desse contexto [11]. As DSL’s têm a vantagem de serem focadas num problema em especifico e de permitir prototipar mais facilmente a aplicação final, mas têm a desvantagem de necessitarem de um esforço de aprendizagem maior para a sua utilização [11].

Exemplo – Do PIM ao Código

Para esclarecer os conceitos de PIM e PSM e para dar a entender, um pouco, o processo de desenvolvimento baseado em MDA irá ser apresentado um pequeno exemplo rascunho. No exemplo existem duas entidades (Cliente e Encomenda) e o objetivo é fazer um PIM que suporte a migração para qualquer tipo de SGBD existente. Foi utilizada a ferramenta de modelação Visual Paradigm para o desenvolvimento do seguinte PIM.

Figura 6 – Exemplo de um PIM

Como podemos verificar, o PIM é completamente independente da plataforma (Diagrama de Classes UML) e apenas representa os atributos e as relações das entidades. Através deste PIM é então possível gerar vários PSM’s dependendo do SGBD que pretendemos. Os SGBD

escolhidos foram o MySQL e o PostgresSQL e assim foram obtidos os seguintes modelos de

dados.

Figura 7 – Exemplo de um PSM (PostgresSQL)

Model Driven Architeture

Como é possível observar, através de um único modelo conseguimos obter outros dois dependentes da plataforma. O próximo passo é conseguir obter o código de implementação das tabelas na respetiva linguagem, coisa que é possível devido às ferramentas do Visual Paradigm. Assim, para cada PSM foi obtido o seguinte código.

Figura 9 – Exemplo de código PostgresSQL

Figura 10 – Exemplo de código MySQL

Tipos de Transformações

Como é possível observar na Figura 4, e como foi referido nos capítulos acima, existem diferentes tipos de transformações no processo de desenvolvimento baseado em MDA. As transformações que são responsáveis por transformar PIM’s em PSM’s, são designadas por transformações Model-to-Model (M2M) e as que transforam PSM’s em código fonte são designadas por transformações Model-to-Text (M2T). Estes dois tipos de transformações são feitas através de ferramentas automáticas (como a ferramenta Visual Paradigm), que de forma muito simplista, não são mais do que um conjunto de regras que, quando agrupadas, definem como um modelo numa determinada linguagem pode ser transformado num outro modelo numa linguagem destino.

Model Driven Architeture

16

Ferramentas existentes

A MDA depende muito do uso de ferramentas, já que estas desempenham o papel mais importante de todo o processo, as transformações. Quando um PIM é produzido, é iniciado um processo automático de transformação, responsável por transforma-lo num PSM e consequentemente em código. Este processo de transformação é conseguido através da utilização de ferramentas, que recebem o PIM como input e geram um PSM que mais tarde é transformado em código (através da mesma ferramenta ou de uma outra auxiliar) [12].

Figura 11 – Ciclo de transformação através de ferramentas

A escolha da ferramenta é por isso, um passo determinante para o sucesso e para a qualidade do desenvolvimento. Uma boa ferramenta de transformação deve [6]:

 Suportar diferentes plataformas;

 Fornecer flexibilidade suficiente para migrar entre plataformas;  Suportar linguagens de modelação distintas (UML incluído);  Integrar com outras ferramentas de desenvolvimento de software.

Devido ao facto de o processo de transformação apresentar grande complexidade e devido ao facto de o desenvolvimento de uma ferramenta que suporte todos os pontos acima apresentados ser muito complexo, existem ferramentas que apenas suportam a transformação PIM/PSM, outras que suportam PIM/PSM/Código e como seria de esperar outras que suportam PSM/Código (mais comuns).

Como exemplo de ferramentas que implementam transformações desde o PIM até ao código final, temos algumas ferramentas CASE como o Visual Paradigm e o Enterprise Architect que utilizam UML para definição dos modelos e permitem a geração de código para inúmeras linguagens. Nestas ferramentas o processo de transformação é bidirecional, ou seja, as alterações feitas num determinado PIM são refletidas num PSM, mas o contrário também se verifica.

Model Driven Architeture

Vantagens e desvantagens

Como foi referido no capítulo 2.1, o processo de desenvolvimento de software tradicional tem alguns problemas, problemas esses que a MDA tenta resolver da melhor maneira possível. É sabido que não existem formas perfeitas para o desenvolvimento de software, cada paradigma/metodologia tem as suas vantagens e desvantagens, cabendo à equipa de desenvolvimento decidir qual a melhor aproximação a utilizar.

Uma das vantagens de salientar é a clara separação entre PIM’s, PSM’s e ferramentas automáticas de transformação. Isto garante que os responsáveis pelo desenvolvimento dos PIM´s, não necessitem de se preocupar com detalhes específicos das plataformas e podem focar a sua atenção na especificação da funcionalidade que melhor se adequa aos utilizadores finais. Por outro lado, ao nível dos PSM’s é produzido muito menos código, pelo facto de uma grande porção deste ser automaticamente produzido [5].

Com a utilização do MDA, a questão da portabilidade é largamente simplificada. A portabilidade é, facilmente, atingida pelo facto de o mesmo PIM poder gerar diferentes PSM’s para diferentes plataformas e tecnologias.

Para além das vantagens a nível técnico, é também importante referir que através da utilização de MDA é possível garantir a padronização de código fonte e é conseguida uma agilização e flexibilidade no tempo de resposta a problemas.

Como todas as abordagens, existem problemas e desvantagens que têm de ser tidos em conta. No que toca ao MDA, é de salientar o facto de ser introduzida alguma rigidez no processo de desenvolvimento, ou seja, pelo facto de se programar menos e se gerar mais, nem todos os pormenores podem ser alterados e manipulados (pelo menos sem alterar o próprio gerador). Outro problema que é importante salientar, é a mudança dos papéis dos elementos da equipa já que, a necessidade de programação é menor e a necessidade de especificação do sistema é acrescida [13].

Arquitetura Vortal Next>

3 Arquitetura Vortal Next>

Este capítulo tem como intuito fazer uma breve abordagem da arquitetura da plataforma Vortal Next>, explicando os principais conceitos internos e os componentes da mesma. Será abordada e explicada a abordagem seguida pela empresa Vortal para implementar a

metodologia MDA em termos de inputs, outputs e das transformações desde o processo de

definição do PIM até ao código final.