A primeira rede social sobre arquitetura de software do Brasil

Utilização de POA (Programação Orientada a Aspectos) para adaptação de software

Olá amigos da Pangea....

Tenho pesquisado muito na área de POA (Programação Orientada a Aspectos), já fiz algumas apresentação em seminários acadêmicos e empresas e já brinquei bastante com isto em JAVA e em .NET

Eu tenho uma idéia a qual pretendo propagar por ai que é a de utilizar POA para a criação de Módulos Adicionais (adaptações de rotinas para clientes específicos) em sistemas.

Minha idéia é a seguinte:
1 ) Supondo que o programa já criado é um produto de uma empresa de software, e é vendido e baixado por diversos clientes.
2 ) Como o programa é um produto ele vem com diversas funções genéricas que atende de forma ampla
3 ) Neste momento um cliente que compra este sistema e tem a necessidade de alterar uma das rotinas, ele quer que ao se clicar no botão de imprimir o relatório, ao invés deste ser impresso como de costume, aparecerá uma tela solicitando algumas informações e então sim imprimirá o relatório;

Até então o que vejo de mais comum é alterarmos a tela em si, criando variáveis e condicionais para mudar o fluxo do programa.

(Sei que tem muitos sistemas que superam este tipo de coisa gente, estou falando de um caso que costumo ver em diversos sistemas menores, não do Microsiga por exemplo...)

Então a idéia é manter o sistema criado original sempre intacto, criando um aspecto que atuaria no ponto especificado do sistema quando necessário.

Acredito que isto acabaria com o problema de uma alteração feita em uma tela para um determinado cliente afete outros clientes.

Tags: .net, a, adaptação, aop, aspect, aspectos, módulo, orientada, poa, programação

▶ Responder esta

Respostas a este tópico

Permalink Responder até Charles Fortes em 11 fevereiro 2009 at 13:06: Gostaria de saber o que vocês acham sobre isto?

A idéia é válida? Vocês já chegaram a fazer algo parecido?

=)

Vamos discutir....; ▶ Responder esta

Permalink Responder até Adriano Tavares em 27 fevereiro 2009 at 21:48: Olá Charles,
a sua idéia é válida e plenamente implementável com POA. POA é realmente uma técnica bastante eficiente para implementação de modularização mas isso não é tudo. Você certamente vai precisar também documentar, especificar e desenhar as aplicações. Um excelente livro que aborda este assunto é Aspect-Oriented Software Development with Use Cases de Ivar Jacobson. Ele trata dos seguintes assuntos:

- Construção de casos de uso e aspectos
- Como capturar e modelar preocupações com casos de uso
- Mantendo preocupações separadas com módulos de casos de uso
- Modelar fatias de casos de uso e aspectos usando extensões da UML (***)
- Aplicar casos de uso e aspectos em projetos

*** Acredito que a sua idéia pode evoluir apartir daqui. Com esta técnica você poderá inserir e retirar casos de uso inteiros das aplicações.

Bons aspectos!!!!

abs
--
Adriano

Charles Fortes disse:
Gostaria de saber o que vocês acham sobre isto?

A idéia é válida? Vocês já chegaram a fazer algo parecido?

=)

Vamos discutir....; ▶ Responder esta

Permalink Responder até Charles Fortes em 27 fevereiro 2009 at 22:32: Olá Adriano,

Valeu pela força, vou dar uma olhada no livro sim.

Abraços; ▶ Responder esta

Permalink Responder até Jener Menezes em 5 março 2009 at 23:06: Oi Charles,
como sou novo no Pangea, vou contribuir apenas agora com minha experiência em AOP.

Utilizamos mais em sistemas que realmente necessitem de algum tipo de code inject. Pois sua utilização, no sentido do sistema ficar mais escalonável e flexível a mudanças, etc, não creio ser uma boa prática. Pois é mais complexo para ser desenvolvido, uma vez que o desenvolvedor sempre cai (GoTo Definition) em uma Interface ou Classe Abstrata ou Classe Base sem Implementação, fazendo com que o desenvolvedor, principalmente aquele que não participou do projeto desdo o início, com uma produtividade mais baixa.

Agora, para quem realmente precisa utilizar, recomendo um framework que já utilizei e estamos ainda utilizando chamado Spring.NET que é bem parecido com o Spring JAVA. Você pode encontrá-lo em http://www.springframework.net.; ▶ Responder esta

Permalink Responder até Charles Fortes em 6 março 2009 at 0:22: Olá Jener,

Muito obrigado por compartilhar sua experiência. Também havia visto a dificuldade de utilizar o AOP para customizações justamente por este ponto. Para que funcione a documentação tem que estar em um nível não muito comum (infelizmente) e caso um funcionário que não acompanhou necessite dar manutenção perde produtividade (ao ler e entender a documentação e localizar o problema).

Outra questão que tento levantar é: vale a pena o esforço gasto?

Por um certo lado penso que sim, pois podemos manter um aplicativo homologado no mercado e as adaptações criadas não interferem no funcionamento do sistema comum.

Perde-se na hora de necessitar de manutenção, porém ganha-se ao evitar desgastes causados por "erros de nova versão". Além disto acredito que necessidade de manutenção em uma customização pode ser reduzida com uma boa metodologia, boas práticas, bons testes... enfim...

Então, vale o esforço?; ▶ Responder esta

Permalink Responder até Edmundo em 7 março 2009 at 15:16: A solução que vou indicar aqui não é nova: trata-se de um velho padrão (pattern) aplicado na década de 70 pelos pioneiros em programação orientada a objetos (linguagem Smalltalk).
Imaginemos a seguinte situação:
Em março de 2009, o cliente pede que um formulário eletrônico seja apresentado sempre que a opção "Imprimir" seja acionada através do menu do sistema. Após o preenchimento do formulário, o relatório será impresso (click no botão "Iniciar impressão") ou não (click no botão "Cancelar impressão"). A equipe então implementa a funcionalidade.
Alguns meses depois, o cliente pede que, ao final da impressão, seja enviado um e-mail de notificação para o administrador. A equipe atende o pedido.
Passado algum tempo, o cliente pede que cada impressão seja registrada para cobrança a partir da segunda via impressa. A equipe atende o pedido.
Se queremos um código de qualidade e extensível, a equipe não deveria precisar alterar o método que responde ao evento de click na opção do menu, em nenhum dos casos do apresentados!
Então como deixar esse método flexível? Basta fazer com que esse método varra uma lista contendo objetos que implementam uma interface (ou herdam de uma classe abstrata) padronizada e chame, para cada objeto, o método padronizado (ex: atenderPedidoImpressao ou AtenderPedidoImpressao). Com isso, deixamos o controle dos passos de impressão no método, mas delegamos a outros objetos os comportamentos específicos desejados. Outra parte do sistema seria responsável por configurar essa lista, adicionando ou removendo objetos (ex: solicitarPreenchimentoJustificativa, executarImpressao, notificarUsuario, bilhetarImpressao). Outra vantagem dessa técnica é que não foi necessário utilizar nenhum IF em toda a solução. A propósito, cada instrução IF introduzida no código aumenta sua complexidade ciclomática (McCabe) e aumenta consideravelmente o número de cenários de teste de unidade necessários para atingir um nível de cobertura de código adequado (100%, para deixar seus usuários mais confiantes no código que vai para a produção).
Uma última recomendação é que o método padronizado pela interface retorne um valor booleano para indicar se a seqüência de passos deve prosseguir (ex: botão iniciar impressão) ou ser interrompida (ex: botão cancelar impressão).; ▶ Responder esta

Permalink Responder até Edmundo em 7 março 2009 at 15:33: O maior objetivo do uso de aspectos é deixar o seu código limpo. Ninguém programa orientado a aspectos, você continua programando orientado a objetos e, ao usar aspectos, consegue evitar a escrita daqueles códigos repetitivos, tais como:
- abrir e fechar (rollback ou commit) a transação de banco de dados em cada método da camada de serviços de sua aplicação;
- lançar registros de log para fins de contagem de acessos (bilhetagem) ou de auditoria;
- verificar se o usuário autenticado está apto a executar o serviço selecionado;
- acessar de forma padronizada serviços do sistema operacional ou do monitor de transações corporativo.

Charles Fortes disse:
Olá Jener,

Muito obrigado por compartilhar sua experiência. Também havia visto a dificuldade de utilizar o AOP para customizações justamente por este ponto. Para que funcione a documentação tem que estar em um nível não muito comum (infelizmente) e caso um funcionário que não acompanhou necessite dar manutenção perde produtividade (ao ler e entender a documentação e localizar o problema).

Outra questão que tento levantar é: vale a pena o esforço gasto?

Por um certo lado penso que sim, pois podemos manter um aplicativo homologado no mercado e as adaptações criadas não interferem no funcionamento do sistema comum.

Perde-se na hora de necessitar de manutenção, porém ganha-se ao evitar desgastes causados por "erros de nova versão". Além disto acredito que necessidade de manutenção em uma customização pode ser reduzida com uma boa metodologia, boas práticas, bons testes... enfim...

Então, vale o esforço?; ▶ Responder esta

Permalink Responder até Luiz Carlos Faria em 4 novembro 2009 at 20:33: Acredito e gosto de usar POA com outros patterns, principalmente o IoC. Minha visão sobre POA se estende também à contextualização. Sempre vejo a necessidade de implementar algo que sofre modificações de comportamento em função do contexto, vejo uma boa oportunidade para o aspecto. Um caso que tenho trabalhado bastante é com SaaS, onde determino o tenant por aspectos. Existem milhares de aplicações para POA e existem també outros padrões que podem substituí-la em alguns casos. No teu exemplo, onde você está falando de resposta a eventos, eu tenho uma opinião diferente da sua. Eu olho para o problema e vejo muito mais a necessidade de uma implementação de mensageria, como um publisher/subscriber, por exemplo. Mas enfim, existem milhares de aplicações e formas de alcançar o mesmo objetivo.; ▶ Responder esta