AN style="FONT-SIZE: 10pt; BACKGROUND: white; COLOR: red; FONT-FAMILY: Verdana; moz-background-clip: -moz-initial; moz-background-origin: -moz-initial; moz-background-inline-policy: -moz-initial">
tyle="MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: left" align=left>Gerência de configuração de arquiteturas utilizando modelos. Esse artigo apresenta uma breve introdução ao desenvolvimento dirigido por modelos (MDD) com algumas tecnologias Java, que foram usadas como exemplos para configurar arquiteturas utilizando o modelo de features.
Para que serve:
Descrever um modelo para documentar tecnologias que configuram arquiteturas. Além de documentar a composição de uma arquitetura, o modelo permite ao arquiteto gerenciar mudanças nas tecnologias durante o desenvolvimento de um sistema utilizando o MDD.
Em que situação o tema é útil:
No desenvolvimento de uma aplicação, é possível combinar muitas tecnologias, que configuram uma arquitetura. Uma arquitetura dita ideal deve permitir que novas tecnologias substituam tecnologias mais antigas sem a necessidade de recodificar grandes trechos de uma aplicação. Para isto, é necessário que o arquiteto gerencie as modificações nas tecnologias das arquiteturas. O modelo de features é uma boa solução para gerenciar configurações de arquiteturas. Arquiteturas especificadas com este modelo simplificam as adaptações de aplicações para novas tecnologias.
Configuração de Arquiteturas no MDD – Resumo DevMan:
O desenvolvimento dirigido por modelos (MDD) permite maior produtividade no desenvolvimento de aplicações que utilizam tecnologias Java. Apesar de ferramentas CASE para MDD focarem na geração de código, existem outras características que o tornam muito mais interessante para obter maior produtividade. Uma destas características é a possibilidade de gerenciar aplicações em camadas dependentes de tecnologias. Outra é documentar e gerenciar as configurações das arquiteturas Java utilizando modelos.
Nesse sentido, a configuração das tecnologias usadas em arquiteturas é um requisito para se obter maior produtividade no MDD. Esta configuração pode ser realizada utilizando o modelo de features e a gerência da mesma pode ser realizada com a abordagem FOMDA (ver referência 4). O modelo de features e a abordagem FOMDA permitem ao arquiteto gerenciar aplicações em níveis abstratos das tecnologias.
Arquiteturas de desenvolvimento de software são temas freqüentemente discutidos em empresas de TI. Isto porque a implementação de uma arquitetura depende de muitas tecnologias, e estas mudam com freqüência. As tecnologias podem determinar uma maior produtividade das equipes de desenvolvimento, porém elas nem sempre são encaradas com naturalidade pelas equipes e pelas empresas de TI. Muitas vezes, as empresas optam pelo uso de tecnologias mais antigas em função do alto custo da mudança.
No entanto, essa mudança pode, hoje, ser menos traumática e menos custosa se utilizarmos práticas de Desenvolvimento Dirigido por Modelos (MDD). O uso do MDD nas empresas de TI pode minimizar o impacto ocasionado pelas modificações feitas nas tecnologias que implementam a arquitetura, auxiliando na maximização da produção de software. Este artigo pretende introduzir ao leitor esta nova abordagem de desenvolvimento de software.
A possibilidade de especificar grande parte dos requisitos de um sistema em um modelo traz benefícios, como a possibilidade de transformar o mesmo modelo em código-fonte compilável de diferentes tecnologias. Quanto mais detalhes forem especificados em modelo, maior é a quantidade e a qualidade de código que pode ser gerado. A qualidade do código gerado depende também do sistema gerador de código, denominado como ferramenta CASE. Muitas empresas já estão se beneficiando com o uso do MDD.
Esse artigo é focado nas arquiteturas de desenvolvimento utilizadas em Java e aborda como o arquiteto Java pode gerenciar as mudanças nas arquiteturas de desenvolvimento utilizando modelos. Para isto, contextualizamos o termo MDD com a definição de arquiteturas formadas por tecnologias Java.
Arquiteturas Java
As arquiteturas baseadas em Java permitem que o desenvolvimento de software se aproxime de um bom cenário para a empresa de TI em termos de produtividade. As freqüentes novidades tecnológicas para desenvolver sistemas em Java fortalecem o uso da linguagem e facilitam o desenvolvimento dos sistemas. No entanto, não é tão fácil para um arquiteto acompanhar e estruturar estas novidades, sendo necessário avaliar ganhos e perdas das empresas para adotá-las no mercado. Qualquer modificação em uma arquitetura de desenvolvimento de software é sempre realizada com muita cautela pela empresa de TI. O motivo é que toda a adaptação tem um custo.
Para definir a arquitetura dita ideal, alguns requisitos devem ser atendidos. Dependendo do domínio das aplicações, a arquitetura ideal deve permitir executar os softwares em muitas plataformas, como em web, Dekstop e Mobile. Além disso, o software desenvolvido na arquitetura deve executar em diferentes plataformas sem a necessidade de muitas modificações. A arquitetura também deve permitir a especificação de novos requisitos de um sistema, além do reuso daqueles codificados em aplicações semelhantes. Por mais que se tente definir uma arquitetura ideal, a mudança freqüente nos requisitos dos sistemas pode impedir sua utilização em todos os casos.
Neste sentido, o arquiteto Java deve configurar uma arquitetura que possa ser modificada à medida que novas tecnologias são integradas. Frameworks, como o Spring, facilitam o trabalho do arquiteto para integrar em uma arquitetura novas tecnologias Java. Apesar disso, modificar uma arquitetura não é uma tarefa trivial, pois o número de possíveis combinações entre as tecnologias Java é muito grande. Para ter uma dimensão das tecnologias Java que podem configurar uma arquitetura, o leitor pode visualizar as possíveis combinações entre todas as tecnologias apresentadas nas edições anteriores da Java Magazine. São muitas combinações possíveis. A cada ano, surgem novidades que viabilizam uma melhor produtividade no desenvolvimento de aplicações. Mas com freqüência, uma nova tecnologia traz consigo uma série de dependências que dificultam o trabalho do arquiteto.
A empresa de TI e as novas tecnologias
As novidades nas tecnologias Java, apesar de acrescentarem em produção, também trazem um problema para a empresa de TI. Elas implicam em custos adicionais. Alguns custos estão relacionados com o esforço necessário para definir a nova arquitetura e também com os esforços dos programadores no aprendizado das novas tecnologias.
Outro problema para a empresa de TI adotar uma nova arquitetura está relacionado ao reuso de código de aplicações legadas. Ainda que se aproveite muito do código produzido com as tecnologias Java no desenvolvimento de uma nova aplicação, a cada mudança na arquitetura o código das aplicações legadas precisa ser alterado para ser reusado. Modificada a arquitetura, uma parte do código (mesmo que numa pequena parcela) não pode ser aproveitada como está. Sabemos que Java é flexível e permite a customização da arquitetura, bem como uma rápida adaptação do código. No entanto, independente da qualidade do código-fonte desenvolvido ou de padrões de projeto utilizados, uma modificação na arquitetura trará custos de manutenção.
O arquiteto Java
Apesar do custo adicional, as mudanças na arquitetura de desenvolvimento são necessárias na empresa de TI. Houve um tempo, por exemplo, em que a melhor arquitetura Java para desenvolver aplicações que rodavam na web era baseada no padrão de projeto MVC2, usando JSP e Servlets. Atualmente, temos um cenário que aponta para o Spring Framework ou o Struts como a melhor escolha para web e, ainda, JavaServer Faces para especificar interfaces de usuário. É tarefa de um arquiteto gerenciar essas modificações. Esta tarefa pode iniciar com a identificação das camadas que podem compor uma aplicação.
A Figura 1 apresenta um exemplo de algumas camadas que podem compor uma aplicação. O arquiteto precisa definir quais são as tecnologias presentes em cada camada, configurando assim a arquitetura. Muitas tecnologias podem ser utilizadas para cumprir com um determinado fim, no entanto uma arquitetura configurada pelo arquiteto irá requerer apenas algumas delas.
