Neste artigo veremos os principais problemas associados à preservação da arquitetura de software durante a fase de construção e como contornar esse problema com a utilização de aspectos por meio do AspectJ.
Em que situação o tema útil:
Para qualquer projeto de software, são importantes definições arquiteturais que conduzem as formas como o software será implementado na fase de construção. No entanto, para muitos arquitetos e desenvolvedores, manter uma arquitetura preservada pode se tornar uma tarefa difícil. Pensando nisso, esse artigo trás uma solução barata e automatizada com o uso de AspectJ.
Resumo DevMan:
Este artigo propõe uma exploração sobre o paradigma da programação orientada a aspectos. O objetivo dessa exploração é propor sua utilização como uma maneira de garantir a conformidade arquitetural em projetos de software. Com a implementação de uma série de exemplos utilizando aspectos, foram criados restritores de violações na arquitetura de software definida para um projeto. O artigo coloca como violações arquiteturais a não conformidade no design arquitetural, políticas de código, convenções de nomeação, padrões de projeto e melhores práticas de programação. A ferramenta utilizada para descrever os exemplos nesse estudo foi o AspectJ. Por fim, as conclusões sugerem que o uso de aspectos para inibir os desvios arquiteturais por meio de declarações em tempo de compilação é um recurso poderoso e ao mesmo tempo barato, diante da diversidade de opções existentes para realizar a mesma tarefa. Contudo, isso não isenta uma análise criteriosa na escolha de uma solução eficaz para manter a conformidade arquitetural.
Este artigo pretende demonstrar, por meio de exemplos, o uso da Programação Orientada a Aspectos (POA) como uma ferramenta de apoio à preservação e ao reforço da arquitetura de projetos de software, políticas de código, padrões de projetos, melhores práticas de programação e interações válidas entre módulos de um sistema. Ele possui como base teórica o artigo desenvolvido por Merson (2007), onde é descrita uma brilhante aplicação da programação orientada a aspectos (POA) para definição de erros ou avisos de tempo de compilação para preservar as definições arquiteturais de um projeto de software. Com isso, pretende-se realizar uma análise desse primoroso trabalho, verificando, de forma pragmática, a possibilidade do uso da POA para temas voltados à preservação arquitetural. Segundo Merson (2007), POA “[...] é um paradigma de programação que facilita a modularização de interesses transversais”. É possível, portanto, explorar seu uso como um validador entre a arquitetura formulada e a de fato executada, ou seja, aquela implementada pelos desenvolvedores do projeto. O uso da POA como um validador da arquitetura é motivado pelas constantes diferenças encontradas entre a arquitetura planejada e a real. Tais diferenças são denominadas desvios arquiteturais.
De acordo com Terra e Valente (2010), os desvios arquiteturais que ocorrem durante a fase de implementação de um projeto podem provocar a erosão arquitetural – produção de efeitos inesperados na aplicação, devido ao distanciamento entre a arquitetura real e a projetada. Isso ocorre devido ao desrespeito aos condutores arquiteturais definidos na fase de elaboração de um projeto de software, levando à perda, durante a fase de construção, de condutores como manutenibilidade, reusabilidade, escalabilidade, portabilidade, entre outros.
Para exemplificar essa situação, pode-se pensar em algum padrão de projeto definido como necessário, para promover a reusabilidade de uma arquitetura de um projeto de software. Durante a fase de construção, não existia nenhuma forma de verificar se tal padrão de projeto estava sendo construído corretamente ou não. Com isso, algumas partes do sistema estavam utilizando o padrão de projeto definido e outras não. Consequentemente, esse comportamento comprometeu a reusabilidade definida anteriormente pelo arquiteto de software e fez com que a arquitetura real se distanciasse da projetada.
Os projetos de software, muitas vezes, exigem o envolvimento de uma equipe de diversos profissionais. Dentre estes, a equipe de desenvolvedores é o elemento chave para “pragmatizar” a arquitetura estabelecida por um ou mais arquitetos. Segundo Terra e Valente (2010), normalmente, um arquiteto pode definir as diretrizes de construção de um projeto de software por meio da arquitetura concreta – também conhecida como arquitetura implementada, caracterizada por estar representada no código fonte – ou por meio de uma arquitetura planejada – também conhecida como arquitetura documentada, definida por meio de modelos e documentos arquiteturais do projeto de software. Terra e Valente (2010) citam que ambas devem ser seguidas pelos desenvolvedores, na fase de construção dos casos de uso. No entanto isso nem sempre ocorre, por motivos que variam desde a inexperiência de desenvolvedores até problemas com o prazo de entrega de projetos. Muitas vezes, ainda conforme Terra e Valente (2010), tais motivos são os responsáveis por violações arquiteturais de diversos gêneros, gerando o não atendimento dos requisitos arquiteturais pré-estabelecidos durante a fase de elaboração da arquitetura.
Com base no que foi previamente analisado, o propósito deste artigo é demonstrar o emprego da POA para assegurar a integridade da arquitetura de software. O uso da POA além do combate às violações arquiteturais pretende também promover dinamismo e economia de tempo na fase de construção de projetos. Isso será demonstrado por meio de uma revisão literária que incluirá outras fontes de referências, além das citadas por Merson (2007). Os tipos de violação de arquitetura citados nesse artigo são problemas recorrentes durante a fase de construção do software dentro dos projetos de sistemas.
Configurações para implementação e testes de exemplos com AspectJ
Para implementar e testar os exemplos desse artigo em um projeto Java, realize as seguintes instruções:
· Instale o AspectJ em seu computador (veja [1] na seção Links) ou adicione-o via IDE Eclipse (veja [2] na seção Links);
· Copie e cole todos os exemplos de código dentro de um único aspecto público (ex. public aspect RestricaoArquitetural {...}), e depois salve o arquivo como RestricaoArquitetural.aj, por exemplo;
· Direcione o código do aspecto para os pacotes que seu projeto estiver utilizando. (Os exemplos neste artigo utilizam com.asp.proj);
...
