MAC 413/5715 - Tópicos de Programação Orientada a Objetos

Trabalho de Programação Orientada a Aspectos

• A escolha do software a ser "aspectizado". Escolham, preferencialmente (mas não obrigatoriamente) um programa ou sistema conhecido. Esse software deve ser livre, deve ser escrito em Java e deve ter certo porte. Estou sendo deliberadamente vago neste último requisito. Para efeito deste trabalho, um sistema com mais de 10000 linhas de código Java "tem certo porte". Já o programa de 400 linhas que você escreveu para a disciplina MACxyz não tem. Situações intermediárias serão analisadas caso a caso.

• A natureza da "aspectização" a ser feita. Vocês podem escolher entre duas modalidades de trabalho: refatoramento orientado a aspectos e adição de característica não funcional.
  1. Refatoramento orientado a aspectos. Aqui o objetivo é usar orientação a aspectos para melhorar a modularidade do software escolhido (ou de partes dele), sem alterar a sua funcionalidade. O roteiro básico tem as seguintes etapas:
     1. identificar uma ou mais "funcionalidades" implementadas por linhas de código que estão dispersas por vários métodos e classes,
     2. remover essas linhas de código do software e
     3. re-implementar as funcionalidades removidas como aspectos.
  2. Adição de característica não funcional. O termo "característica não funcional" se refere a uma característica ortogonal à funcionalidade normalmente percebida pelos usuários do software. Ele é aplicado a características como suporte a logging, suporte a profiling, segurança (controle de acesso), atomicidade transacional, persistência de dados, etc. Aqui a idéia é usar orientação a aspectos para adicionar alguma dessas coisas a um sistema já existente.

  Estou especialmente interessado em trabalhos de refatoramento orientado a aspectos. Se você conhece bem o software livre X e tem uma boa idéia sobre como melhorar a modularidade desse software usando orientação a aspectos, então não deixe de fazer um trabalho desse tipo! Se você não tiver nenhuma idéia assim, não há problema: faça um trabalho na modalidade 2, adicionando uma característica não funcional a algum software livre que você já conheça.

• A escolha da linguagem ou framework orientado a aspectos. Aqui a opção é entre AspectJ e JBoss AOP.

• Um conjunto de arquivos-fonte com as modificaçoes no software escolhido.
• Um arquivo README explicando como gerar o software modificado. O processo de geração do software deve ser automatizado, preferencialmente com o ant.
• Uma monografia sobre o trabalho. A monografia deve incuir:
  • uma descrição sucinta do software que a equipe escolheu para "aspectizar",
  • uma descrição detalhada da "aspectização" efetuada,
  • uma avaliação crítica do resultado do trabalho,
  • uma avaliação crítica da linguagem ou framework orientado a aspectos empregado.

Exemplo de trabalho na modalidade 1: aspectização das classes que fazem empacotamento/desempacotamento de dados no JacORB

Todos os dados transmitidos/recebidos pelo JacORB devem ser empacotados/desempacotados segundo as regras da Common Data Representation (CDR) padronizada por CORBA. Duas classes fazem esse serviço: org.jacorb.orb.CDROutputStream, cuja responsabilidade é empacotar dados e escrevê-los no stream de saída, e org.jacorb.orb.CDRInputStream, cuja responsabilidade é ler dados do stream de entrada e desempacotar esses dados. A primeira dessas classes tem métodos de escrita para múltiplos tipos de dados CORBA: write_boolean, write_char, write_string, etc. A segunda classe tem os correspondentes métodos de leitura.

Certas regras da CDR correspondem logicamente a "aspectos" que intercruzam vários métodos das classes CDROutputStream e CDRInputStream. Uma dessas regras diz respeito ao alinhamento dos dados empacotados. O CDR especifica que números de 32 bits (longs ou floats) devem sempre começar num endereço (relativo ao início do buffer de escrita ou leitura) que é múltiplo de 4, que números de 64 bits (longlongs ou doubles) devem sempre começar num endereço múltiplo de 8, etc. O código que implementa essas restrições de alinhamento intercruza vários métodos das classes CDROutputStream e CDRInputStream. Ele poderia ser extraído dessas classes e substituído por um aspecto que lida com alinhamento.

Outra regra diz respeito ao "chunking" de seqüências de dados que representam objetos passados por valor. Tais seqüências podem ser divididas em pedaços ("chunks"), os quais podem ser transmitidos/recebidos individualmente. Cada "chunk" tem um cabeçalho que informa o tamanho do pedaço. O código que lida com esses "chunks" intercruza muitos métodos da classe CDRInputStream. (Digamos que algúem chamou read_long, mas o long a ser lido está bem no início de um "chunk". O método read_long precisa estar preparado para encontrar um "chunk header" antes do long.) Esse código poderia ser extraído da classe CDRInputStream e substituído por um aspecto que trata do "chunking".