Implementa¸c˜ oes da MDA

Existem diversos autores que prop˜oem implementa¸c˜oes da MDA que resultam por vezes em ferramentas que concretizam essas implementa¸c˜oes. Estas fer- ramentas s˜ao feitas quer pelos autores, quer por empresas que utilizam essas implementa¸c˜oes. Dois exemplos de ferramentas implementadas s˜ao as ferramen- tas propostas por Stephen Mellor et al. [56] e por Oscar Pastor et al. [69], em que algumas das implementa¸c˜oes j´a est˜ao em pr´atica.

Regra geral, a forma como estes autores especificam as implementa¸c˜oes do MDA ´e pela defini¸c˜ao de um perfil UML. Juntamente com este perfil (subcon- junto/adapta¸c˜ao da UML) s˜ao necess´arias linguagens de defini¸c˜ao de restri¸c˜oes bem como de especifica¸c˜ao de comportamento.

O processo de transforma¸c˜ao de modelos ´e completamente definido. ´E ne- cess´ario que seja definida a semˆantica, detalhes da plataforma e tudo o que ´e abstra´ıdo do processo de modela¸c˜ao [56]. Em todos os m´etodos apresentados pelos autores, como seria de esperar isto ´e fundamental.

Em Executable UML [56] o autor descreve o modelo com use cases. De seguida implementa os modelos, em que o componente estrutural ´e descrito com diagramas de classes. Os ciclos de vida dos componentes s˜ao especificados com diagramas de estado. O processo de desenvolvimento ´e um processo iterativo de escrita de modelos, escolha do compilador, teste do resultado e caso n˜ao seja satisfat´orio, volta-se `a fase de escrita dos modelos, para os refinar. Para defini¸c˜ao de comportamento em MDA Explained [49] adoptado o AS, em MDA in practice [69] ´e utilizada a linguagem OASIS.

No livro MDA in practice [69] ´e definido o processo MDA baseado em quatro modelos. Estes modelos s˜ao baseados em quatro tipos de especifica¸c˜oes: funci- onais, comportamentais, de comunica¸c˜ao e decomposi¸c˜ao. Estes s˜ao os compo- nentes considerados essenciais para modelar um software. Os modelos que as concretizam s˜ao de objectos, de dinˆamica, funcionais e de apresenta¸c˜ao. ´E de

notar que a interac¸c˜ao dos utilizadores com o sistema tamb´em ´e contemplada na fase de modela¸c˜ao.

Em MDA in Practice [69] os modelos s˜ao tamb´em definidos num subcon- junto de UML. ´E tamb´em utilizado OCL como linguagem de restri¸c˜oes junta- mente comOASIS. Tamb´em o OO-Method descrito neste livro permite a gera¸c˜ao de c´odigo pronto a compilar em solu¸c˜oes a partir de modelos. Um ponto central desta abordagem ´e a linguagem OASIS uma vez que permite obter as vantagens do formalismo de uma forma facilitada.

Ainda em Executable UML [56] ´e introduzido o conceito de modelo de um dom´ınio, que ´e uma abstrac¸c˜ao de parte do problema. Estes dom´ınios em con- junto formam o modelo que representa a abstrac¸c˜ao do sistema. Estes dom´ınios s˜ao representados sob a forma de diagramas de classes UML, onde ´e usado OCL para especificar as restri¸c˜oes. As restri¸c˜oes s˜ao inclu´ıdas nas classes com os s´ımbolos ’{’ e ’}’, sendo descritas algumas restri¸c˜oes como as que encontramos na linguagem Structured Query Language (SQL), como chave prim´aria, chave estrangeira, etc.

O compilador ´e o componente final essencial ao processo. Deve ser ade- quado `a plataforma, ambiente e desempenho pretendido. Pode ser comprado ou desenvolvido por quem concebe os modelos. O importante ´e que este compilador mapeia as entidades abstractas em entidades da linguagem destino.

O c´odigo gerado pelo compilador ´e denominadoarqu´etipo. Segundo Stephen Mellor et al. [56] este c´odigo n˜ao tem que ser leg´ıvel e mais que isso n˜ao deve ser lido e alterado, porque todas as altera¸c˜oes devem ser feitas ao n´ıvel do modelo. Esta abordagem ´e incompat´ıvel com a j´a descrita implementa¸c˜ao incremental, onde era permitida a altera¸c˜ao do c´odigo.

Para que a MDA seja mais usada ´e ainda necess´ario que seja feita uma padroniza¸c˜ao de alguns conceitos, como das linguagens que permitam modela¸c˜ao completa. Na teoria a MDA est´a pronta para ser usada, e exemplo disso ´e o facto de j´a estar em uso no mercado, e provando que a perda de performance dos modelos compilados n˜ao ´e um grave problema [56]. Na pr´atica ´e preciso ainda algum trabalho para que esta seja mais utilizada.

Estes processos descritos pelos autores podem ser, na maioria dos casos, directamente mapeados nos elementos constituintes da MDA, com algumas li- mita¸c˜oes (como por exemplo em Executable UML [56] onde ´e ignorado o PSM). Regra geral todas as abordagens tˆem uma representa¸c˜ao directa dos modelos, das ferramentas, das linguagens e do c´odigo produzido.

Nestas abordagens um dos temas analisado foi a integra¸c˜ao do processo MDA com software j´a existente. Um dos autores que aborda esta tem´atica f´a-lo de uma forma pr´atica mas limitativa. O OO-Method descreve o processo de in- tegra¸c˜ao de software existente denominado Legacy Systems. Estes modelos s˜ao abstra´ıdos em Legacy Views, onde os componentes do software s˜ao representados em classes. Estes componentes tornam-se ent˜ao parte integrante do sistema a ser modelado. Estes componentes, quando abstra´ıdos como classes tˆem proprie-

2.4. INFER ˆENCIA DE C ´ODIGO E MODELOS 25 dades e m´etodos. Dos Legacy Systems apenas ´e poss´ıvel aceder `as propriedades que eles exp˜oem, uma vez que por defini¸c˜ao n˜ao podem ser alterados. A Le- gacy View ´e a modela¸c˜ao orientada a objectos de um sistema pr´e-existente. A sua defini¸c˜ao ´e semelhante `a de outras classes uma vez que tamb´em s˜ao uma abstrac¸c˜ao estrutural e comportamental. Enquanto representa¸c˜ao gr´afica estes elementos s˜ao marcados com o estere´otipo legacy. S˜ao ent˜ao tratados e interli- gados com as outras classes. Passam a fazer parte do problema ao mesmo tempo que contribuem para a solu¸c˜ao final.

Esta solu¸c˜ao de integra¸c˜ao de solu¸c˜oes existentes pode n˜ao ser a ideal, uma vez que n˜ao permite a altera¸c˜ao do sistema existente. Ele passa a ser como uma caixa negra, onde apenas se podem usar alguns componentes que s˜ao os que ele exp˜oe ao sistema existente. Por outro lado a recupera¸c˜ao completa do modelo de um sistema pr´e-existente tem muitas mais vantagens, como por exemplo a altera¸c˜ao do mesmo. Isto poder´a ganhar mais interesse ainda, se falarmos por exemplo na fase de manuten¸c˜ao de uma aplica¸c˜ao da qual n˜ao exista um modelo. Assim, esta solu¸c˜ao proposta aparece mais como uma atenua¸c˜ao ao problema do que uma resolu¸c˜ao.