A IMPORTÂNCIA DOS REQUISITOS NÃO FUNCIONAIS NO DESENVOLVIMENTO DE UM SISTEMA ORIENTADO A ASPECTO

José Augusto Zanotto Franklin

Resumo


Durante anos, os engenheiros de softwares lutam quanto à estruturação de códigos, a fim de maximizar sua reutilização e diminuir o risco de defeitos. Enquanto a Programação Orientada a Objeto (POO) fornece uma estrutura sólida para a organização de códigos, acaba apresentando dificuldades para reutilizar características transversais, levando a duplicações desnecessárias de códigos e a um aumento de erros na fase de produção, causando uma diminuição na qualidade e tempo de mercado. O trabalho proposto tem por objetivo apresentar essa nova ideia de Programação Orientada a Aspecto (POA) o qual seu objetivo se define em separar os níveis de preocupação durante o desenvolvimento de software. A metodologia consistiu numa revisão bibliográfica sobre o tema e a programação de um sistema com uso dos conceitos da POA. Durante as pesquisas, constatou-se que é possível pensar separadamente nos problemas referentes à persistência dos dados, modelagem de negócios, segurança, distribuição auditoria, registros de logs etc. Para facilitar o levantamento destas características transversais, se torna viável basear-se pelos requisitos não funcionais, visto que os mesmos são de impacto em várias camadas do sistema, pois tratam especificamente de particularidades relacionadas ao uso da aplicação em termos de desempenho, usabilidade, confiabilidade, segurança, disponibilidade, manutenibilidade, assim como tecnologias envolvidas. Para o funcionamento desse paradigma, é necessário o conhecimento de alguns conceitos os quais são a base da POA, sendo eles: (i) Advice (conselho), é a implementação do aspecto, ou seja o código e a regra do que, e quando será executado ou ponto de corte. (ii) Pointcut (Ponto de corte), definem onde será executado o Advice, unindo a um JoinPoint. (iii) JoinPoint (Ponto de Junção), definem os pontos onde os códigos (Aspectos) podem ser inseridos no fluxo normal do sistema. A POA é dividida em 3 fases, (Decomposição, implementação e recomposição). A Decomposição é voltada para a eliciação dos aspectos que serão implementados. A implementação é a subdivisão dos aspectos em classes separadas das regras de negócio assim como a criação de seus momentos de execução, e a recomposição dessa estrutura a qual se dá através do Weaving, responsável por executar a solução juntando os códigos de aspecto juntamente com o sistema em execução. Para demonstrar a eficácia da POA, o trabalho consistiu no desenvolvimento de um sistema de caixa eletrônico, o qual apresenta uma solução em POO, e sua refatoração em POA, facilitando a identificação de pontos fortes na utilização desse novo conceito. Como considerações destaca-se que a POA, não deve ser pensada como um novo padrão de programação, e sim como um complemento para a POO, visto que trata de preocupações diferentes, tendo como seu objetivo facilitar a reutilização de códigos, deixando assim com uma estrutura de fácil manutenção, entendimento e com maior facilidade de evolução devido sua facilidade de reutilização de códigos.

Palavras-chave


Aspecto, POA, RNF



REVISTA UNIPLAC
ISSN 2447-2107
EDITORA UNIPLAC | PORTAL DE REVISTAS UNIPLAC
e-mail: propepg@uniplaclages.edu.br | Fone: (49) 3251-1009
Copyright 2012. Editora UNIPLAC