Evaluaci´ on

Quando o usuário interage com a aplicação e executa o cenário na versão V0, requisi- ções geradas pelo browser por meio do protocolo HTTP geram invocações que passam pe- las várias camadas do sistema, sendo a primeira delas a camada Controller do framework Struts, a qual é composta por uma complexa cadeia de mecanismos. Essas invocações navegam por esses mecanismos até alcançarem as classes Actions da aplicação, que são LoginAction e InitAction. Os métodos invocados nessas Actions acessam a camada de serviço, cujos métodos acessam a camada DAO, que por sua vez acessa o banco de dados. Para reproduzir essa interação do usuário com a aplicação, o JMeter foi congurado para gerar essas requisições, chamadas nesse trabalho de invocações externas, e um plano de ex- perimento foi congurado no JMeter, composto por requisições HTTP que apontam para um caminho que aciona o cenário de autenticação do usuário. No arquivo struts.xml da aplicação, uma conguração de Action representando essa autenticação de usuário, cujo nome é simulateLoginUser, é responsável por interceptar as chamadas e redirecioná-las para uma segunda conguração de Action, que é initPortal. Da mesma forma, essa segunda conguração redireciona as chamadas para um método onde a execução prosse- gue. Essas congurações são responsáveis por redirecionar as chamadas para métodos que compõem o cenário. O plano do experimento congurado no JMeter gera as requisições para o Controller da aplicação, que executa em um servidor Tomcat congurado em uma máquina local, previamente inicializado por uma conguração de Maven build, conforme detalhado na Seção 4.1. Na Figura 4.7 é representado o caminho das invocações externas através da aplicação. Os números representam a ordem de execução dos eventos. Os passos 10 e 21 existem apenas nas versões da região E do mapa de versões.

4.5. Tipos de Invocações 67

Figura 4.7: Caminho das invocações externas através da aplicação.

interna. A razão da criação desse tipo de invocação foi reduzir o caminho da invocação através da aplicação e com isso concentrar as medições apenas nas camadas de serviço e DAO. Para a geração dessas invocações internas, uma classe JUnit chamada Experiment- Test foi criada simulando o comportamento das invocações externas, mas sem conter a complexa cadeia de mecanismos do framework Struts. As invocações internas são gera- das pela classe JUnit que acessa ambos passos do cenário proposto sequencialmente. A implementação desses passos, no entanto, não invoca os serviços diretamente, mas sim métodos nas Actions que invocam os serviços após um processamento interno. Na Figura 4.8 é representado o caminho das invocações internas através da aplicação. Na Figura 4.9 é apresentado o código da classe JUnit.

Figura 4.8: Caminho das invocações internas através da aplicação.

Na classe de testes JUnit as variáveis são inicializadas entre as linhas 19 e 33, onde alguns valores iniciais são atribuídos e as injeções de dependências são conguradas por meio da anotação Autowired. Um bloco de inicialização entre as linhas 35 e 39 é res- ponsável por invocar o garbage collection antes da execução de cada teste. O método loggingNoAOP() é invocado no teste por meio da anotação na linha 41 e é responsável por invocar os dois passos do cenário dentro de um loop que itera o número de vezes

congurado pela variável loopCount. O tempo da geração dessas invocações é medido por meio da classe StopWatch, onde a contagem é iniciada na linha 45 e termina na linha 50. O resultado do tempo gasto em valor absoluto é impresso no console por meio do código da linha 51 e a média de tempo por invocação é impressa por meio do código da linha 53. As linhas comentadas demonstram códigos utilizados em algumas versões, conforme detalhado na Seção refsecao:design.

Figura 4.9: Código da classe JUnit utilizada para a geração das invocações internas. As invocações internas foram criadas com base na hipótese de que a complexa cadeia de mecanismos do framework Struts, juntamente com a presença do acesso ao banco de dados consome uma quantidade considerável de recursos que, nesse estudo, são representados pelas variáveis dependentes. Se essa hipótese está correta, as medições das variáveis dependentes são fortemente inuenciadas pela presença desses dois elementos na aplicação. O uso das invocações internas para algumas etapas do experimento, onde o banco de dados é desabilitado, serviria para evitar que tais elementos inuenciassem nas medições e dessa maneira possibilitaria a medição dos fatores propostos de maneira isolada.

De forma a conrmar ou rejeitar essa hipótese, um pequeno experimento foi realizado. A conrmação sugere que as invocações internas devem ser consideradas no experimento,

4.5. Tipos de Invocações 69

pois a cadeia de mecanismos do framework Struts e a presença do acesso ao banco de dados realmente consomem uma quantidade considerável de recursos e isso pode causar impacto na análise dos fatores de POA propostos. A rejeição dessa hipótese, por outro lado, sugere que as invocações externas são o suciente para a realização do experimento. Uma vez que métricas de desempenho como CPU ou memória necessitam de uma ferramenta especíca para tais medições, o tempo foi utilizado como métrica de medição por ser facilmente obtido por diversos meios. O teste foi composto por duas partes:

1. Medições de invocações externas: para executar esse teste, a versão V1-A foi im- plantada em um servidor Tomcat local e o JMeter foi congurado para gerar 1.000 requisições HTTP de forma sequencial apontando para a Action que inicia o cená- rio. O plano do experimento do JMeter foi executado 10 vezes. Na Tabela 4.1 são apresentados os resultados das médias de tempo por invocação, apresentadas pelo relatório do JMeter.

Tabela 4.1: Resultados de 10 médias de tempo por invocação externa apresentadas pelo relatório do JMeter.

Execução 1 2 3 4 5 6 7 8 9 10

Tempo(ms) 295 296 296 296 296 296 296 296 297 297

2. Medições de invocações internas: a classe JUnit foi congurada para executar o método loggingNoAOP na versão V1-A. A variável loopCount, conforme detalhado na Seção 4.6, foi congurada com valor 1.000. O teste foi executado 10 vezes e o tempo gasto na execução foi apresentado no console do Eclipse após cada execução. Na Tabela 4.2 são apresentados os resultados das médias de tempo por invocação. Tabela 4.2: Resultados de 10 médias de tempo por invocação, calculadas a partir da classe StopWatch e divididas por 1.000.

Execução 1 2 3 4 5 6 7 8 9 10

Tempo(ms) 1,537 1,546 1,547 1,571 1,612 1,616 1,616 1,618 1,681 1,711

Os resultados apresentados na Tabela 4.2 são os resultados da divisão do total de tempo gasto por 1.000, fornecidos pelo código da linha 53 da classe de testes JUnit a cada chamada de teste. A média de tempo por invocação, considerando todos os resultados foi de 1,605 ms, enquanto a média de tempo nas invocações externas foi de 296,1 ms. Essa diferença conrma a hipótese, direcionando as invocações externas para serem utilizadas apenas quando POA é analisada no contexto geral, onde se consideram elementos de grande inuência nas variáveis dependentes propostas, que é o caso das versões da região E do mapa de versões. O caminho completo percorrido pelas invocações através da cadeia de mecanismos do framework Struts consome uma quantidade considerável de recursos de tempo, sem mencionar outros recursos como CPU e memória, o que direciona as invocações internas para serem consideradas

o tipo de medição mais adequado para o experimento para as versões das regiões A,B,C e D do mapa de versões, onde os fatores propostos são analisados de maneira isolada.